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
> 
>