Re: [cclib-devel] orbitals for correlated methods

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

On Monday 27 August 2007 12:54, Adam Tenderholt wrote:
> > 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).
>
> For the unrestricted calculation, are you proposing indices 0/1 are
> for the alpha/beta MOs, and 2/3 for the alpha/beta NOs?
Exactly - and similarly for geomatry optimizations even/odd for alpha/beta. If 
the calculation is restricted, then only alpha of course.

> Also, how do you propose determining whether a calculation is a
> 4-step restricted with just MOs or a single step unrestricted
> calculation with both MOs and NOs?
Yes, that is a bit problematic. You can check if geovalues exists, for 
example, but at present we don't parse mocoeffs each time if they are printed 
in each step anyway (we should, I guess, alhtough I don't need that). 
Ultimately, the user would need to know what kind of job was being parsed.

I just imagined a geometry optimization with both MOs and NOs printed :) so 
this idea is getting pretty complicated. Do you think the implementation with 
nocoeffs is a better idea?

-- 
written by Karol Langner
Mon Aug 27 19:00:29 EDT 2007