cclib-devel

[cclib-devel] etenergies

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

I'd like to open a little discussion about parsing excited states. I uploaded 
a CIS job and am wondering on how the parsing of excited states should look 
like in cclib. Should etenergies (and the other etxxx attributes) pick up 
excited states from any kind of calculation - TDHF, CI, etc.? Or should there 
be separate attributes for the different kinds of calculations. The question 
is similiar to the one we had earlier - having mpenergies and ccenergies 
versus one attribute for correlated energies.

Karol

-- 
written by Karol Langner
Sun Mar  4 15:18:52 CET 2007

Re: [cclib-devel] etenergies

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

I would put them all into etxxx. Is there anything extra or different
about a CIS calculation? We are talking about "transitions to excited
states" rather than "excited states" themselves, right?

On 04/03/07, Karol Langner <kar...@kn...> wrote:
> I'd like to open a little discussion about parsing excited states. I uploaded
> a CIS job and am wondering on how the parsing of excited states should look
> like in cclib. Should etenergies (and the other etxxx attributes) pick up
> excited states from any kind of calculation - TDHF, CI, etc.? Or should there
> be separate attributes for the different kinds of calculations. The question
> is similiar to the one we had earlier - having mpenergies and ccenergies
> versus one attribute for correlated energies.
>
> Karol
>
> --
> written by Karol Langner
> Sun Mar  4 15:18:52 CET 2007
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> cclib-devel mailing list
> ccl...@li...
> https://lists.sourceforge.net/lists/listinfo/cclib-devel
>

Re: [cclib-devel] etenergies

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

Well, I guess if we parse the excitation energies, then the total energies of 
the excited states are redundant? As to CI calculations, there is some 
specific information about the excited states (for example the coefficients 
for MO excitations).

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.

On Sunday 04 of March 2007 22:16, Noel O'Boyle wrote:
> I would put them all into etxxx. Is there anything extra or different
> about a CIS calculation? We are talking about "transitions to excited
> states" rather than "excited states" themselves, right?
>
> On 04/03/07, Karol Langner <kar...@kn...> wrote:
> > I'd like to open a little discussion about parsing excited states. I
> > uploaded a CIS job and am wondering on how the parsing of excited states
> > should look like in cclib. Should etenergies (and the other etxxx
> > attributes) pick up excited states from any kind of calculation - TDHF,
> > CI, etc.? Or should there be separate attributes for the different kinds
> > of calculations. The question is similiar to the one we had earlier -
> > having mpenergies and ccenergies versus one attribute for correlated
> > energies.
> >
> > Karol

-- 
written by Karol Langner
Mon Mar  5 10:42:04 CET 2007

Re: [cclib-devel] etenergies

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

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.

> 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.

> 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! :-)

> On Sunday 04 of March 2007 22:16, Noel O'Boyle wrote:
> > I would put them all into etxxx. Is there anything extra or different
> > about a CIS calculation? We are talking about "transitions to excited
> > states" rather than "excited states" themselves, right?
> >
> > On 04/03/07, Karol Langner <kar...@kn...> wrote:
> > > I'd like to open a little discussion about parsing excited states. I
> > > uploaded a CIS job and am wondering on how the parsing of excited states
> > > should look like in cclib. Should etenergies (and the other etxxx
> > > attributes) pick up excited states from any kind of calculation - TDHF,
> > > CI, etc.? Or should there be separate attributes for the different kinds
> > > of calculations. The question is similiar to the one we had earlier -
> > > having mpenergies and ccenergies versus one attribute for correlated
> > > energies.
> > >
> > > Karol
>
> --
> written by Karol Langner
> Mon Mar  5 10:42:04 CET 2007
>

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
>

Re: [cclib-devel] etenergies

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

On Tuesday 06 of March 2007 10:46, Noel O'Boyle wrote:
> > > > 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).

Thought I might mention, that the Gaussian parser nicely parses CI jobs 
presently, at least the one test I uploaded so far.

Karol

-- 
written by Karol Langner
Wed Mar 14 21:27:23 CET 2007

Re: [cclib-devel] etenergies

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

On Tuesday 06 of March 2007 10:46, you wrote:
> > > 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! :-)

In the trunk, etenergies is now parsed for CIS output from Gaussian and 
GAMESS. Now, the GAMESS parser doesn't parse TD-DFT/HF... so should there be 
a checkmark in the appropriate box in the 'Parsed data' table? This is not 
meant to be an argument for the implicit/explicit discussion (I am for 
keeping just etenergies), just a note that we need to clear out some policies 
for ambiguous attributes (used for various kinds of output).

Karol

-- 
written by Karol Langner
Wed Mar 14 22:02:18 CET 2007