Re: [cclib-devel] oscillator strengths/transition dipoles (was: etsecs conversions)

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

On 28/03/07, Karol Langner <kar...@kn...> wrote:
> On Tuesday 27 of March 2007 19:55, Karol Langner wrote:
> > But, there seems to be a problem related to the excitation coefficients
> > (which need a tolerance above 0.0005, by the way). Namely, some of the
> > coefficients printed by Gaussian have different signs than the ones printed
> > by GAMESS (observe also that the ones given by Jaguar are consistently with
> > an extra minus compared to GAMESS). This is probably due to the symmetry
> > type (A1, B1, A2, ...). I don't know what the relation is, however, and we
> > should standardize this. Any ideas? Notice that the appropriate new test in
> > testCI.py fails.
>
> After some thought and conversations with colleagues, I can't think of any
> physical/chemical reason that the coefficients would have different signs.
> After all, only their squares have meaning in terms of the Hamiltonian - so
> their sign could be the byproduct of numerical assumptions in the code.

I don't know anything more about this than you, but the magical
'phase' value of + or - comes up often when solving calculations. For
example, the IR vibrational displacements can have opposite signs in
different programs. So the O-H stretch can become an O-H squeeze. They
are conceptually equivalent, but depending on the eigenvector solver
(or something) that you use, the signs can turn out differently.

> The sign, however, should influence the transition moments and so also the
> oscillator strengths.
Are you sure? In my mind, the secs are a mathematical construction
that gives a solution to the TD-DFT or CI calculation. It is the sign
of *this* single solution that is important. After all, there is a
single oscillator strength associated with the solution, not several
oscillator strengths, one for each sec. Again, I don't know much about
this. :-)

>I'm not too surprised that Gaussian and GAMESS give
> entirely different trnsition dipoles and oscillator strengths (compare the
> water_cis jobs in both programs). An I mean entirely - Gaussian often gives
> zero (0.0000) where GAMESS gives significantly non-zero numbers. In Jaguar,
> again different numbers - although here they qualitively agree with those in
> GAMESS and so might result from numerical differences. I don't understand
> this, or I'm not reading the numbers right.
I think we're hitting the limit of our knowledge here. :-)

> These considerations may not be what cclib is about, but I guess it's
> important for cclib to parse consistently - and probably to only parse things
> that are consistent?
The first is true, but I don't agree with the second. Different
programs might simply be using different algorithms to calculate the
same quantity. What we want to do is to take that information and
present it faithfully to the user so that they can analyse it. It is a
different question to compare and contrast the output of different
comp chem packages...perhaps that's another paper (although I
recommend reading the Gaussian license first of all)!

> Karol
>
> --
> written by Karol Langner
> Wed Mar 28 01:06:11 CEST 2007
>