Re: [cclib-devel] three things

[Noel O'B. <no...@ca...>]

On Sat, 2006-04-22 at 11:20 -0700, Adam Tenderholt wrote:
> > 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?

ADF seems to do things differently, so I guess we should too. I had the
same impression that ADF likes fragments. Since we really, in the end,
want to calculate Mulliken pops, etc. for fragments ourselves, you're
probably right that we should run with ADF on this. In terms of
standardising across different parsers, we may wish to move to a
different naming scheme, i.e. not 'ao', for the fragment-based orbitals
('fo'?) that we are going to use in ADF, or it will be misleading to
users. 

> Adam
> 
> 
> 
> -------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> cclib-devel mailing list
> ccl...@li...
> https://lists.sourceforge.net/lists/listinfo/cclib-devel