Re: [cclib-devel] three things

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

> Print Smat and EPrint SCF Eigvec looks useful, and I uploaded  
> dvb_sp_b.adfout
> as a test. Read the svn log for a description of challenges we face.

Awhile ago I added a simple Mo atom with BAS overlap and coeffs, but  
only commented on it in the svn log. Unfortunately, the presence of  
frozen core orbitals complicates the orbitals. For instance, look at  
the BAS eigenvectors for anything. You can see that they are linear  
combinations of orbitals that include the core basis functions. This  
means, there isn't a 1 to 1 mapping between BAS functions and  
aonames. Bummer. I don't think my understanding of BAS -> CFs -> SFOs  
is good enough to figure out how to create a mapping between BAS and  
real aonames right now. So...

We need to discuss how we'll parse aonames for ADF calculations. I  
see three options:

1) Don't parse aonames unless the molecule has nosymmetry (ie. MO  
labels are are 1A, 2A, etc.)

2) aonames become something like 1C_1S+4C_1S or 1C+4C_1S+1S for the  
"positive" case and 1C_1Px-4C_1Px or 1C+4C_1Px-1Px for the negative  
case.

3) Take time and learn out how to map BAS to aonames. It ought to  
just involve using the Core functions to linearize the valence  
functions. This will be complicated with d and f functions because  
one of the d cartesian function is an "s" orbital, and 3 of the 10 f  
functions are "p" orbitals (says the ADF manual).

My preference is number 2. Since ADF allows "fragment" calculations,  
it would be nice to keep track of the MOs in a basis of the fragment  
MOs instead of atomic orbitals. I can come up with an example of how  
this would be useful if you want. I'm pretty sure doing option 3  
would get rid of this useful info. I'm against option 1 because the  
symmetry labels are also useful information, although it's not quite  
like info from the fragments.

What do you think?

Adam