cclib-devel — Developer's mailing list

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

Re: [cclib-devel] pyquante and cclib

[Rick M. <rm...@sa...>]

Nice! Let me know if I can help with anything.

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?

Rick

On Jul 28, 2006, at 4:16 AM, Noel O'Boyle wrote:

> Hello Adam,
>
> I'm very excited by what we will be able to do with PyQuante/cclib.
>
> After adding the ability to extract the coefficients of the Gaussian
> basis functions from G03 (I've called the attribute 'gbasis' for the
> moment, any comments) [note to self: G03 also exports basis  
> functions in
> a different format depending on the Gaussian revision/version - I  
> cannot
> handle this yet], it is possible to use PyQuante to calculate the
> amplitude of any molecular orbital at any point in space.
>
> That means that we can calculate the electron density! We can do
> population analysis methods like Hirshfeld atomic charges, AIM, etc.,
> etc. (if we know how, of course :-). You should note that calculating
> the electron density will take quite a while but speed can come  
> later if
> we really want to work on this.
>
> I haven't yet added the code to cclib, but see the attached screenshot
> for proof - the volume data derives from cclib/PyQuante, not the cube
> file of a Gaussian calculation. (Visualised with mayavi, the python  
> GUI
> interface to VTK).
>
> Regards,
>   Noel
>
>
> <dvb_homo>

Rick Muller
rm...@sa...

Re: [cclib-devel] pyquante and cclib

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

> I'm very excited by what we will be able to do with PyQuante/cclib.
>
> After adding the ability to extract the coefficients of the Gaussian
> basis functions from G03 (I've called the attribute 'gbasis' for the
> moment, any comments) [note to self: G03 also exports basis  
> functions in
> a different format depending on the Gaussian revision/version - I  
> cannot
> handle this yet], it is possible to use PyQuante to calculate the
> amplitude of any molecular orbital at any point in space.
>
> That means that we can calculate the electron density! We can do
> population analysis methods like Hirshfeld atomic charges, AIM, etc.,
> etc. (if we know how, of course :-). You should note that calculating
> the electron density will take quite a while but speed can come  
> later if
> we really want to work on this.

This is quite exciting! I've always wanted to have a custom, modern  
program for visualizing orbital data, especially one that will allow  
scripting so that a list of desired orbitals can be used instead of  
selecting each one individual from a menu (Molden, ADFGUI).

Out of curiosity, how long are you saying electron density takes for  
a single orbital?

Adam

[cclib-devel] [Fwd: Re: Package independent analysis of comp chem calcs]

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

-------- Forwarded Message --------
From: Rick Muller <rm...@sa...>
To: Noel O'Boyle <no...@ca...>
Subject: Re: Package independent analysis of comp chem calcs
Date: Wed, 26 Jul 2006 09:52:28 -0600
Noel,

I had hoped to clean this up before sending it to you, but it's a  
busy time of the year, and I haven't had the time to dedicate to it.

I've attached a few python modules that I use for parsing Jaguar and  
GAMESS output. To be honest, much of the time I just write  
lightweight parsers from scratch, instead of the attached modules.  
But to read in an overlap matrix or something the routines are useful.

The files have a copyright notice in them, but you may treat them as  
public domain and do what you like with them. Keep me posted on what  
you do. I'll be glad to write the module to output cube files from  
PyQuante, but you might have to nag me once or twice. Best of luck!

Rick
On Jul 13, 2006, at 9:16 AM, Noel O'Boyle wrote:

> On Thu, 2006-07-13 at 08:51 -0600, Rick Muller wrote:
>> Ah, but here's a problem, one of those things that only works when
>> you start writing code.
>>
>>   I was assuming that the basisset be a list of PyQuante basis
>> functions, which have a built-in function .amp(x,y,z) to give the
>> basis function amplitude at the point x,y,z. If you want to do this
>> in cclib you would essentially have to recreate (or steal -- you're
>> welcome to them) the PyQuante functions that define a basis set,
>> normalize it, and compute the amplitudes. This is certainly possible,
>> but it isn't as elegant as one might like.
>> However, I actually use
>> PyQuante functions to do analysis like this all the time. I'll read
>> in a Jaguar or GAMESS output file, parse it for the orbitals,
>> recreate the basis set and overlap matrix in PyQuante, and display
>> information that I want.
> But this is great! This is exactly what I want to do, and you've even
> gotten the parsing code written already. If you're happy to give me  
> this
> code for cclib, that would be fantastic.
>
>> Alternatively, I can simply include code to output a cube file from
>> PyQuante.
> That would be good too. As this is the next step, once the density is
> calculated.
>
> Regards,
>   Noel
>
>> On Jul 13, 2006, at 6:37 AM, Noel O'Boyle wrote:
>>
>>>
>>> I think a first attempt to make a useful bridge between cclib and
>>> PyQuante would be for cclib to provide a function density() as
>>> follows:
>>>
>>> def density(mocoeffs, coordinates, basis set, delta = 0.1, cube =
>>> None):
>>> 	"""Calculate the electron density using PyQuante.
>>>
>>> 	Requires:
>>>           mocoeffs - mol. orb. coefficients in terms of atom  
>>> orbitals
>>> 	  coordinates
>>>           basis set - a set of Gaussian functions per atom
>>> (expressed as
>>>                       per PyQuante user guide)
>>>         Optional:
>>>           delta - the dx/y/z value for points in the cube.  
>>> Defaults to
>>>                   0.1Ang or something sensible.
>>>           cube - the dimensions of the cube. Default is something
>>> sensible
>>>         Returns:
>>> 	  a Numeric array of the density (which can be visualised with
>>>                                           MayaVi for example)
>>>         """
>>>
>>> If this makes sense to you and seems doable, I'll start hacking  
>>> basis
>>> set info out of log files. Of course, I will make sure that the  
>>> above
>>> code will work equally well for users of PyQuante and other comp.
>>> chem.
>>> packages.
>>>
>>> In PyQuante everything is Gaussian-based right? No STOs? If so, that
>>> rules out ADF I think.

Re: [cclib-devel] API change

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

On Tue, 2006-07-25 at 08:23 -0700, Adam Tenderholt wrote:
> Hey Noel,
> 
> > I've been busy getting GAMESS-UK into shape. There haven't really  
> > been any
> > difficulties, although it seems that GAMESS UK doesn't want to  
> > print out
> > all of the mocoeffs of the virtual orbitals (it just does the first  
> > 10 or
> > so)...I'll see if I can ask the developers about this.

Latest update, I've registered to post my query on the GAMESS UK forum,
but am waiting to be OKed.

> Glad to hear you've been working on this. Jaguar also only prints a  
> handful of virtual orbitals unless you tell it to print more.  
> Speaking of which, do you want me to check in the little bit of  
> Jaguar code I have? It just parses aonames, moceoffs, and aooverlaps  
> as needed from PyMOlyze.

Absolutely, I didn't realise you had some already (I've actually just
checked in some aooverlaps code) - if you're happy, why don't don't you
take over finishing Jaguar. I think we're going to need some more
calculations though, as the uploaded ones don't seem to be comprehensive
[there's a time limit on my access to Jaguar and GAMESS-UK at this
stage, i.e. I'll be leaving here at the end of August - hence the reason
I'm trying to get as much done as possible now].

> > I've also been trying to get GaussSum to use cclib. I'm getting  
> > there, but
> > I realise I need to add a .clean() method to the superclass of the  
> > parsers,
> > which removes all of the calculated attributes. The reason is that  
> > I need
> > to allow users to reparse their log files as a calculation  
> > progresses, and
> > the easiest (and cleanest) way to do this seems to be to wipe the  
> > parser
> > clean and reparse.
> 
> I didn't realize GaussSum actually monitored the progress of a  
> calculation. Do you just open up a file, and every so often GaussSum  
> parses it? That's a neat idea. Adding a clean() method sounds  
> completely reasonable.

Well, it's not quite automatic. You have to click the button. :-) But it
does tell you whether the SCF/geometry is likely to convergence, rather
than just oscillate for ever.

Regards,
  Noel

Re: [cclib-devel] API change

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

Hey Noel,

> I've been busy getting GAMESS-UK into shape. There haven't really  
> been any
> difficulties, although it seems that GAMESS UK doesn't want to  
> print out
> all of the mocoeffs of the virtual orbitals (it just does the first  
> 10 or
> so)...I'll see if I can ask the developers about this.

Glad to hear you've been working on this. Jaguar also only prints a  
handful of virtual orbitals unless you tell it to print more.  
Speaking of which, do you want me to check in the little bit of  
Jaguar code I have? It just parses aonames, moceoffs, and aooverlaps  
as needed from PyMOlyze.

> I've also been trying to get GaussSum to use cclib. I'm getting  
> there, but
> I realise I need to add a .clean() method to the superclass of the  
> parsers,
> which removes all of the calculated attributes. The reason is that  
> I need
> to allow users to reparse their log files as a calculation  
> progresses, and
> the easiest (and cleanest) way to do this seems to be to wipe the  
> parser
> clean and reparse.

I didn't realize GaussSum actually monitored the progress of a  
calculation. Do you just open up a file, and every so often GaussSum  
parses it? That's a neat idea. Adding a clean() method sounds  
completely reasonable.

Adam

[cclib-devel] API change

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

Hello Adam,

I've been busy getting GAMESS-UK into shape. There haven't really been any 
difficulties, although it seems that GAMESS UK doesn't want to print out 
all of the mocoeffs of the virtual orbitals (it just does the first 10 or 
so)...I'll see if I can ask the developers about this.

I've also been trying to get GaussSum to use cclib. I'm getting there, but 
I realise I need to add a .clean() method to the superclass of the parsers, 
which removes all of the calculated attributes. The reason is that I need 
to allow users to reparse their log files as a calculation progresses, and 
the easiest (and cleanest) way to do this seems to be to wipe the parser 
clean and reparse.

Regards,
  Noel 

[cclib-devel] ANNOUNCE: cclib-0.5 available

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

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

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

Among other data, cclib extracts:

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

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

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

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

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

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

Regards,

 The cclib development team

[cclib-devel] Ready for releasing 0.5 final

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

I have updated the licenses and references to 0.5b, and merged the changes 
to the release branch, so we are ready to roll on 0.5 final. I will make 
the release early next week if you have no objections.

Regards,
  Noel

[cclib-devel] [Fwd: [OpenBabel-Devel] Fwd: SourceForge.net SVN trouble]

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

-------- Forwarded Message --------
From: Geoffrey Hutchison <ge...@ge...>
To: openbabel-DISCUSS list <ope...@li...>,
openbabel-devel <ope...@li...>
Subject: [OpenBabel-Devel] Fwd: SourceForge.net SVN trouble
Date: Fri, 14 Jul 2006 09:58:35 -0400

Begin forwarded message:

> From: Egon Willighagen <ewi...@un...>
> Date: July 14, 2006 1:29:56 AM EDT

> Hi all,
>
> we all have all had our trouble with SVN since yesterday, and I  
> think I
> tracked down why. A Debian server was compromised proving the  
> existence of an
> exploit for a kernel security issue, and on the same day SF takes
> shell/svn/cvs access for a kernel exploit too (must be the same one):
>
> "( 2006-07-13 09:23:52 - Project CVS Service, Project Shell  
> Service, Project
> Subversion (SVN) Service, SourceForge.net Web Site  )   A recent  
> kernel
> exploit was released that allowed a non admin user to escalate  
> privileges on
> the host pr-shell1. We urge all users who frequent this host to  
> change their
> password immediately and check their project group space for any  
> tampering.
> As a precaution, we have blocked access to all project resources by  
> password
> until the user resets their password. After the password has been  
> reset,
> project resources should be accessible within 5 minutes."
>
> So, to enable write access for SVN again, you will have to change  
> your SF
> password, which you can do by logging in on the SF webpage, going  
> to "My
> Page" -> Preferences and choosing [Change Password] (how suprising ;)
>
> After I had done this I could commit to SVN again, though it did  
> require me to
> authenticate with my passward, as it was not done automatically  
> using my SSH
> key.
>
> Egon
>
> -- 
> CUBIC
> blog: http://chem-bla-ics.blogspot.com/



-------------------------------------------------------------------------
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
_______________________________________________
OpenBabel-Devel mailing list
Ope...@li...
https://lists.sourceforge.net/lists/listinfo/openbabel-devel

Re: [cclib-devel] LGPL

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

> Is there anything you'd like me to focus on for the 0.5 final release?

I think it's just a case of getting it out there now. Let's declare a
feature and bug freeze.

If you have some spare time you might think about a way to make your
equations look nicer on the wiki (I think there's a way to do this on
the mediawiki help page somewhere in cyberspace). There's a TODO list
somewhere on the wiki on the Developer's page. I'm not brave enough to
look at it, but you may want to add to it, or better still, remove
things from it :-)

Noel

Re: [cclib-devel] LGPL

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

> A very good answer - I think you've summed the situation up  
> exactly. The
> LGPL it is, then. I'm happy with this. And I know you are too.
>
> Today, I'll replace COPYING.txt or LICENSE.txt or whatever it's  
> called.
> I'll also look into replacing the docstring at the start of every  
> python
> file with something succinct as regards the license and copyright. I'm
> thinking something along the lines of:
> cclib, http://cclib.sf.net, (c) 2006, the cclib development team
> cclib is licensed under the LGPL (web ref)

Excellent. :o)

>
> As I mentioned before, it would be useful to have some 'help' text  
> here
> also - even something very basic. I don't think this is a priority
> before we release 0.5 final (since the web site gives quite reasonable
> help), but it's something to bear in mind.

Is there anything you'd like me to focus on for the 0.5 final release?

Adam

Re: [cclib-devel] [Pyquante-users] Package independent analysis of comp chem calcs

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

On Wed, 2006-07-12 at 14:32 -0600, Rick Muller wrote:
> Should certainly be possible to make a more robust interface.  
> Currently the HF and DFT codes have the following interface:
> 
>  >>> h2 = Molecule('H2',atomlist = [(1,(0,0,-0.7)),(1,(0,0,0.7))])
>  >>> energy, orbital_energy, orbitals = dft(h2)
> 
> If you also have the basis set, you can compute both orbital  
> amplitudes and densities at points in real space.
> 
> Let me know if I can help in any way. I've written code along these  
> lines before, and can probably dig up something close to what you need.

Sounds good. I'd like to see that code if you can find it.

I think a first attempt to make a useful bridge between cclib and
PyQuante would be for cclib to provide a function density() as follows:

def density(mocoeffs, coordinates, basis set, delta = 0.1, cube = None):
	"""Calculate the electron density using PyQuante.

	Requires:
          mocoeffs - mol. orb. coefficients in terms of atom orbitals
	  coordinates
          basis set - a set of Gaussian functions per atom (expressed as
                      per PyQuante user guide)
        Optional:
          delta - the dx/y/z value for points in the cube. Defaults to
                  0.1Ang or something sensible.
          cube - the dimensions of the cube. Default is something sensible
        Returns:
	  a Numeric array of the density (which can be visualised with
                                          MayaVi for example)
        """

If this makes sense to you and seems doable, I'll start hacking basis
set info out of log files. Of course, I will make sure that the above
code will work equally well for users of PyQuante and other comp. chem.
packages.

In PyQuante everything is Gaussian-based right? No STOs? If so, that
rules out ADF I think.

Noel

P.S. Let me know if you want to move this discussion from the pyquante
users list.

Re: [cclib-devel] LGPL

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

On Wed, 2006-07-12 at 12:50 -0700, Adam Tenderholt wrote:

> > It's just that I'm about to modify all of the license pages now, and
> > want to sort this out before I start doing this.
> 
> I still think we should make cclib LGPL. Whether we use LGPL or the  
> Python license, we still won't be allowed to use GPL code unless we  
> relicense under GPL. And I figure we would never be adding GPL code  
> since we're basically writing everything from scratch (except stuff  
> we initially wrote under GPL and have since decided to release under  
> a different license). So I don't see any advantages using a Python  
> license has.
> 
> My understanding of the requirements the LGPL would place on  
> derivative works is that it would have to be distributed as a library  
> under the LGPL and the modifications be available. At least this is  
> how it seems things are working between KHTML devs and Apple. Correct  
> me if I'm wrong...
> 
> Finally, if you have specific issues with using the LGPL let me know.  
> I think both of us are relatively flexible, and just have preferences  
> based on pre-conceived ideas. If there is any solid reason not to use  
> one of the licenses (like we did with the GPL), then I think it  
> should be stated and that it only makes sense to use the other.

A very good answer - I think you've summed the situation up exactly. The
LGPL it is, then. I'm happy with this. And I know you are too.

Today, I'll replace COPYING.txt or LICENSE.txt or whatever it's called.
I'll also look into replacing the docstring at the start of every python
file with something succinct as regards the license and copyright. I'm
thinking something along the lines of:
cclib, http://cclib.sf.net, (c) 2006, the cclib development team
cclib is licensed under the LGPL (web ref)

As I mentioned before, it would be useful to have some 'help' text here
also - even something very basic. I don't think this is a priority
before we release 0.5 final (since the web site gives quite reasonable
help), but it's something to bear in mind.

Regards,
  Noel

Re: [cclib-devel] [Pyquante-users] Package independent analysis of comp chem calcs

[Rick M. <rm...@sa...>]

cclib looks cool.



Should certainly be possible to make a more robust interface.  
Currently the HF and DFT codes have the following interface:

 >>> h2 = Molecule('H2',atomlist = [(1,(0,0,-0.7)),(1,(0,0,0.7))])
 >>> energy, orbital_energy, orbitals = dft(h2)

If you also have the basis set, you can compute both orbital  
amplitudes and densities at points in real space.

Let me know if I can help in any way. I've written code along these  
lines before, and can probably dig up something close to what you need.

Rick


On Jul 12, 2006, at 5:19 AM, Noel O'Boyle wrote:

> Dear Rick,
>
> I am one of the developers of cclib (http://cclib.sf.net) which  
> provides
> an interface to the results of comp chem calcs from various  
> proprietary
> comp chem packages. This is currently GPLed, but we may be moving to a
> more liberal license.
>
> A further goal of cclib is to provide some algorithms that allow
> analysis of the results of comp chem calcs in a platform and package
> independent way. Typical examples of some useful algorithms that  
> can be
> carried out after calculations are those that simply involve
> partitioning of the electron density, e.g. Hirshfeld charge analysis,
> AIM, NBO and so on.
>
> I have already coded a small bridge to PyQuante as part of cclib. I am
> interested in expanding this to allow 'recreation' and manipulation of
> the electron density given the basis set details extracted from log
> files. Could you give me any idea whether I will be able to use  
> PyQuante
> to accomplish some of these goals?

[cclib-devel] Package independent analysis of comp chem calcs

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

Dear Rick,

I am one of the developers of cclib (http://cclib.sf.net) which provides
an interface to the results of comp chem calcs from various proprietary
comp chem packages. This is currently GPLed, but we may be moving to a
more liberal license.

A further goal of cclib is to provide some algorithms that allow
analysis of the results of comp chem calcs in a platform and package
independent way. Typical examples of some useful algorithms that can be
carried out after calculations are those that simply involve
partitioning of the electron density, e.g. Hirshfeld charge analysis,
AIM, NBO and so on.

I have already coded a small bridge to PyQuante as part of cclib. I am
interested in expanding this to allow 'recreation' and manipulation of
the electron density given the basis set details extracted from log
files. Could you give me any idea whether I will be able to use PyQuante
to accomplish some of these goals?

Regards,
  Noel

[cclib-devel] LGPL

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

Hello Adam,

I'm back from holidays. And I've fixed that final (for now) bug with the
gaussian parser.

Regarding the licensing; if we include GPL code in cclib, then cclib
needs to become GPL (the opposite isn't true though; they can include
cclib code in their GPL code so long as our license is GPL-compatible,
which most licenses are).

This is the relevant quote from Wikipedia:
"""
Many of the most common free software licenses, such as the original
MIT/X license, the BSD license (in its current 3-clause form), and the
LGPL, are "GPL-compatible". That is, their code can be combined with a
GPLed program without conflict (the new combination would have the GPL
applied to the whole).
"""

To be honest, I'm still leaning towards the Python license, which is
what most Python software has anyway. This means we don't have to worry
about any of this stuff, so long as we don't want to include any
GPL-code in it. PyQuante uses a similar license, as does BioPython. If
you still say LGPL (to ensure pymol has no problems) then we'll do that.
It's just that I'm about to modify all of the license pages now, and
want to sort this out before I start doing this.

Regards,
  Noel