Re: [cclib-devel] etenergies

[Noel O'B. <bao...@gm...>]

On 05/03/07, Karol Langner <kar...@kn...> wrote:
> On Monday 05 of March 2007 17:41, you wrote:
> > On 05/03/07, Karol Langner <kar...@kn...> wrote:
> > > Well, I guess if we parse the excitation energies, then the total
> > > energies of the excited states are redundant?
> >
> > For electronic transitions, we're talking about the vertical
> > excitation energy. The equilibrium energy of the excited state will
> > probably be lower (relaxation). But, it would be redundant as you say
> > if CI is calculating the same thing as TDDFT.
> Do you relaxed as in with an optimized geometry?
Yes.
> >
> > > As to CI calculations, there is some
> > > specific information about the excited states (for example the
> > > coefficients for MO excitations).
> >
> > This sounds like etsecs, but we should check.
> You're right, didn't notice etsecs (where does the name come from anyway?).
Isn't it obvious? :-) Well, it was difficult to come up with a good
name. "singly-excited configurations"='sec'. Each electronic
transition is expressed as a linear combination of single one-electron
transitions in the original molecule (or something like that, I'm a
bit unclear on the specifics). It's a good idea to get an example of
an unrestricted calc for the CI also, as they are usually harder to
parse.

> > > On a related note, I'm in favor of parsing output in a way that makes it
> > > clear what kind of calcualtion was done. In the case of etenergies, the
> > > values can come from TD-HF, CI, or any other excited state method -
> > > perhaps a string attribute such as "etmethod" could label this . The same
> > > point for scfenergies, which can contain energies from HF, DFT, or
> > > whatever, an "scfmethod" attribute mmight be useful. Just an idea.
> >
> > I think you can guess I'm not really keen on this. 'implicit' vs.
> > 'explicit' and so on. Can you think of a 'use case' where this has an
> > advantage? If the result is always treated in the same way by a
> > particular algorithm (e.g. convoluting the UV spectrum is the same no
> > matter what the origin of the data), I think that specialising the
> > data just makes things more difficult. I know that TD-DFT is much
> > different than CI, but I'd be worried about going down that route in
> > general. For example, isn't optimising in internal coordinates
> > different than optimising in cartesian coordinates? OK, it's not so
> > different as TD-DFT vs CI, so maybe you're right! :-)
> Yeah, optimizing in cartesian and internal coordinates is mathematically
> equivalent, the result should be the same :)  but you're right, cclib can't
> account for the "correctness" of the method used. As long as the values are
> supposed to describe the same thing, we should treat it the same way. If
> something specific for CI will be parsed, then there will be a ci<somethinf>
> attribute.
They call this duck-typing in Python; if it walks like a duck, and
quacks like a duck, then it *is* a duck (or at least we can treat it
like a duck).


> --
> written by Karol Langner
> Mon Mar  5 18:52:50 CET 2007
>