Re: [cclib-devel] orbitals for correlated methods

[Karol L. <kar...@kn...>]

On Wednesday 08 August 2007 11:13, Adam Tenderholt wrote:
> > I wrote about this some time ago (see the above), and some thinking
> > made me
> > confident to create a new attribute - nocoeffs. Natural orbitals are
> > mathematically totally different numbers than MO coefficients,
> > although their
> > print-out usually looks very similar. I added code for them in
> > Gaussian and
> > GAMESS for CIS and MP2 - see my commit for details.
>
> Out of curiosity, how do natural orbitals for correlated methods
> differ from those determined from DFT MOs during Weinhold's natural
> bond orders (NBO) method?

MOs, NOs (Natural Orbitals) and NBOs are all orthonormal orbital sets and 
carry the same information - you can use any of them to get properties of the 
entire molecular wavefunction. But they are quite different in how they 
describe the wavefunction. In practice, that means each orbital type is 
different when you visualize it. Also, atomic properties will be different 
since the density is distributed differently among orbitals.

Correlated NOs (Natural Orbitals) are calculated the same way as for 
Hartree-Fock wavefunctions - by diagonalizing the first order reduced density 
matrix (ex. the one-electron CI density). They are eigenorbitals of the 
density operator, and as such provide the most compact description of the 
wavefunction (maximum occupancy). They are indexed by (eigen)occupancies 
instead of (eigen)energies like "regular" MOs.

NBOs AFAIK are certain combinations of Natural Orbitals with the property of 
being localized on a few chemically relevent centers. As the NBO 
documentation states, they "give the most accurate possible Lewis-like 
description of the total N-electron density".

Now to the issue in cclib...
I acted hastily on adding the nocoeffs attribute. There are many types of 
orbital coefficients (NOs, NBOs, optimized MCSCF coefficients) and I now see 
it is better to leave only one attribute for parsing them all. My incentive 
was that sometimes both MO and NO coefficients are printed (see the 
GAMESS-US/water_cis* tests for example) and you may need both (I often do). 
It is more natural for mocoeffs to contain both sets of coefficients - so 
that it would be a list of length 2 (or 4 for unrestricted calculations). 
Similarly, if coefficients are printed in each step of a N-step geometry 
optimization, they should also be parsed and appended in every step, giving a 
length N list (or 2*N).

This solution does not disrupt the current implementation unless a method 
assumes len(mocoeffs)<2, and will limit the number of attributes in the 
future. Finally, all this refers to a pretty rare situation, since most of 
the time molecular orbitals are only printed once in the output as they take 
up alot of space. In the cases where len(mocoeffs)>2, though, it provides a 
nice loophole when using cclib with such output.

Let me know what you think.

Karol

-- 
written by Karol Langner
Mon Aug 27 17:36:45 EDT 2007