Re: [cclib-devel] three things

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

On Thu, 2006-03-30 at 17:04 -0800, Adam Tenderholt wrote:
> 1) I've been working on the ADF parser, however I ran into a problem with 
> reading "aonames". Basically, if there is any symmetry (and nosymmetry isn't 
> specified for the ADF calc), it uses linear combinations of orbitals on 
> different atoms for the atomic basis. As an example, look for the SFOs 
> section on line 1371 of dvb_sp.adfout. SFO 1Ag is constant (C1_1S + C4_1S), 
> where constant is 1/sqrt(2). I can think of two solutions. First, parse it as 
> it is so aonames become something like 1/2 C1_1S + C4_1S. My problem with 
> this is handling more complicated cases with 3+ atoms might lead to more 
> difficult coefficients. Second, ignore it and make sure cclib users know that 
> if they want to do anything with aonames, they need to specify nosymmetry in 
> the ADF calc.

It looks like there are three distinct types of orbitals now: atomic
orbitals, basis set orbitals, and molecular orbitals. Molecular orbitals
are composed of linear combinations of basis set orbitals, which are
composed of linear combinations of atomic orbitals (is this correct?).
For Gaussian, basis set orbitals are equal to the atomic orbitals.

Is there any need to store basis set orbitals in an attribute? So long
as the ADF parser creates a mocoeffs matrix which describes the MOs in
terms of the AOs (and not the basis set orbitals) I think we don't need
the basis set orbitals. 

Regarding the aonames, to be honest, I forget why I wanted to extract
aonames in the first place. In short, I think we should forget about
aonames (I'll remove it from the relevant places if you agree), and
concentrate on getting mocoeff the same between different programs.

> 2) In looking at the Gaussian parser, I wasn't able to find a variable for 
> storing each structure found for a gaussian calculation. What do you think 
> about adding a class for Atoms (name or number, x, y, z in either angs or 
> bohr), a class for Molecules (either a list of Atoms, or more complicated 
> with dictionaries?), and geoms[ ] and geomcoords[ ] in the parser classes?
> 
> 3) What if certain calculations don't implement the same parameters for 
> geotargets/geovalues and scftargets/scfvalues? Look at the differences 
> between the ADF and Gaussian calculations. Is there going to be a variable to 
> keep track of the names for each parameter? Or maybe a set of pre-defined 
> dictionaries (e.g. MaxForce:[ ], RMS Force:[ ], Energy:[ ], dEnergy:[ ], 
> etc.) should be used instead to keep some consistency across each type of 
> calculation?
> 
> Adam
> 
> P.S. Noel, I hope you enjoyed your travels...
>