Re: [cclib-devel] Basis set handling improvements

[Adam T. <ate...@gm...>]

Hey Ben (and everyone else),

It's great that you're thinking about undertaking such an interesting
addition to cclib. It's definitely something that I wanted to get
around to working on, but I've just been plenty busy with research and
such. Anyhow, I have a couple of thoughts about your approach.

You should try to put the basis sets in a format that makes it easy to
eventually convert to the densities that may be of some interest. Can
this be done with matrix operations in numpy?

There's also the promise of OpenCL. This might not help in the
short-term since I don't think that there are drivers that take
advantage of GPUs (my laptop for instance can only work with the CPU),
but it seems like a good long-term approach. One of my former
colleagues has written a Mac application that renders orbitals from
Gaussian calculations on the fly. I don't really know what his plans
are for his program, but I don't think he plans on developing it
commercially. If you're interested, I can see what he thinks and put
you two in contact.

Adam


On Sun, Jan 16, 2011 at 12:10 PM, Benjamin Stein <bs...@un...> wrote:
> Hello, and I hope everyones holidays were nice and relaxing!
>
> I've been thinking about improving the basis set handling in cclib which, as I'm sure everyone knows, looks to be a bit of an undertaking. My eventual goal is to have the handling robust enough to provide methods to generate cube (or whichever format) files of orbitals, densities, etc.
>
> Personally, my motivation (aside from learning how basis sets are handled in various packages) is to play around with orbital transformations, and being able to plot them would be beyond useful. In addition, this would open up doors to possibly visualizing time-dependent results (such as density differences and transition densities).
>
> I'm attacking the problem using a bottom up sort of approach, by working out how to store the basis set information at the primitive gaussian (or slater, I'm trying to be agnostic) level. So far I've sketched out a few simple classes (bear with me, I'm new to this OO stuff).
>
>
> Some thoughts:
>
> Have each atom possess a list of shells. Each shell is composed of primitive functions, each with a contraction coefficient and exponent. This part seems easy-ish; I think I've figured out the parsing of ORCA's basis set output. I haven't looked at Gaussian in a while, but I remember it being reasonable. As long as a package has an option to print out the basis set in some sort of sane format, we should be OK.
>
> A tricky bit is how to handle the 2l+1 m_l components of each shell. None of the packages I've looked at so far have documented the m_l ordering. We can always ask the developers if need be, and I think I've figured it out for ORCA by looking at the output.
>
>
> I've attached some code I put together (I haven't tested any of it, just thinking out loud), but I'm not sure if attachments work on the mailing list. If not I'll just pop it up on dropbox or something.
>
> Best,
> Ben
>
>
>
> Benjamin Stein
> University of New Mexico
>
>
>
>
>
> ------------------------------------------------------------------------------
> Protect Your Site and Customers from Malware Attacks
> Learn about various malware tactics and how to avoid them. Understand
> malware threats, the impact they can have on your business, and how you
> can protect your company and customers by using code signing.
> http://p.sf.net/sfu/oracle-sfdevnl
> _______________________________________________
> cclib-devel mailing list
> ccl...@li...
> https://lists.sourceforge.net/lists/listinfo/cclib-devel
>
>