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