Re: [cclib-devel] Basis set handling improvements

[Karol M. L. <kar...@gm...>]

I was just going to mention Avogadro, too. I think Marcus there is 
separating part of the cube-generating code into a standalone library.

On Tuesday 18 January 2011 16:55:58 Noel O'Boyle wrote:
> Sounds great. You might want to coordinate with Avogadro here, as
> they already have code in the dev version (it's in C++ of course) to
> do something similar. This would save you some work. Also you can
> see what data structure they are using.
>
> - Noel
>
> On 17 January 2011 18:36, Adam Tenderholt <ate...@gm...> 
wrote:
> > 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

-- 
written by Karol Langner
Tue Jan 18 22:04:15 CET 2011