Menu
▾
▴
cclib-devel
|
From: Karol L. <kar...@kn...> - 2007-03-27 12:07:41
|
Hi,
The fragment of the Gaussian parser that reads etsecs:
percent = self.float(t[1])
sqr = percent**2*2 # The fractional contribution of this CI
if percent < 0:
sqr = -sqr
Why are the excitation coefficients squared and multiplied by 2?
Karol
--
written by Karol Langner
Tue Mar 27 10:52:43 CEST 2007
|
|
From: Noel O'B. <bao...@gm...> - 2007-03-27 12:21:31
|
This code may be old and creaky, but the general idea was as follows: (1) You multiply by two because for an excitation from a doubly-occupied orbital there are two excitations in fact...one involving the alpha electron and one involving the beta electron. For an unrestricted calculation, you shouldnt multiple by two. (2) You square because that is the definition of etsecs. It is a somewhat arbitary definition so I am happy to change it. The idea is that these sqr values somehow represent the fractional contribution of a particular SEC to the whole transition. Unfortunately, at least in TD-DFT, this is almost but not exactly true (i.e. these fractional contributions dont add to 1). In fact, this is probably a good unit test to have to make sure that all parsers are doing the same thing. Noel On 27/03/07, Karol Langner <kar...@kn...> wrote: > Hi, > > The fragment of the Gaussian parser that reads etsecs: > > percent = self.float(t[1]) > sqr = percent**2*2 # The fractional contribution of this CI > if percent < 0: > sqr = -sqr > > Why are the excitation coefficients squared and multiplied by 2? > > Karol > > -- > written by Karol Langner > Tue Mar 27 10:52:43 CEST 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 > |
|
From: Karol L. <kar...@kn...> - 2007-03-27 12:30:25
|
On Tuesday 27 of March 2007 14:21, Noel O'Boyle wrote: > This code may be old and creaky, but the general idea was as follows: > > (1) You multiply by two because for an excitation from a > doubly-occupied orbital there are two excitations in fact...one > involving the alpha electron and one involving the beta electron. For > an unrestricted calculation, you shouldnt multiple by two. GAMESS, for example, prints the excitations of both alpha nad beta electrons, even for restricted calculations (see test file "water_cis.out"). The coefficients alpha and beta electrons are always the same. > (2) You square because that is the definition of etsecs. It is a > somewhat arbitary definition so I am happy to change it. The idea is > that these sqr values somehow represent the fractional contribution of > a particular SEC to the whole transition. Unfortunately, at least in > TD-DFT, this is almost but not exactly true (i.e. these fractional > contributions dont add to 1). In fact, this is probably a good unit > test to have to make sure that all parsers are doing the same thing. So we can't really test if they sum up to 1, since they don't :) Another point: as far as I can see, there's no way to force Jaguar to print out triplet excited states. Karol -- written by Karol Langner Tue Mar 27 15:25:35 CEST 2007 |
|
From: Noel O'B. <bao...@gm...> - 2007-03-27 12:38:11
|
On 27/03/07, Karol Langner <kar...@kn...> wrote: > On Tuesday 27 of March 2007 14:21, Noel O'Boyle wrote: > > This code may be old and creaky, but the general idea was as follows: > > > > (1) You multiply by two because for an excitation from a > > doubly-occupied orbital there are two excitations in fact...one > > involving the alpha electron and one involving the beta electron. For > > an unrestricted calculation, you shouldnt multiple by two. > > GAMESS, for example, prints the excitations of both alpha nad beta electrons, > even for restricted calculations (see test file "water_cis.out"). The > coefficients alpha and beta electrons are always the same. > > > (2) You square because that is the definition of etsecs. It is a > > somewhat arbitary definition so I am happy to change it. The idea is > > that these sqr values somehow represent the fractional contribution of > > a particular SEC to the whole transition. Unfortunately, at least in > > TD-DFT, this is almost but not exactly true (i.e. these fractional > > contributions dont add to 1). In fact, this is probably a good unit > > test to have to make sure that all parsers are doing the same thing. > > So we can't really test if they sum up to 1, since they don't :) Sorry - I should have been more clear. They almost sum to 1, and so an assertInside would still be a useful test since if the values sum to something quite different than 1, there is some problem. However, may I suggest redefining etsecs to use the original positive or negative coefficients. The test should use the squared values though. I know we shouldn't redefine the API in a point release, but I feel no responsibility towards API attributes that we didn't test rigourously. > Another point: as far as I can see, there's no way to force Jaguar to print > out triplet excited states. You're saying that it is possible to do the calculation, but just not print out the results? > Karol > > -- > written by Karol Langner > Tue Mar 27 15:25:35 CEST 2007 > |
|
From: Karol L. <kar...@kn...> - 2007-03-27 14:14:22
|
On Tuesday 27 of March 2007 14:38, Noel O'Boyle wrote: > On 27/03/07, Karol Langner <kar...@kn...> wrote: > > On Tuesday 27 of March 2007 14:21, Noel O'Boyle wrote: > > > This code may be old and creaky, but the general idea was as follows: > > > > > > (1) You multiply by two because for an excitation from a > > > doubly-occupied orbital there are two excitations in fact...one > > > involving the alpha electron and one involving the beta electron. For > > > an unrestricted calculation, you shouldnt multiple by two. > > > > GAMESS, for example, prints the excitations of both alpha nad beta > > electrons, even for restricted calculations (see test file > > "water_cis.out"). The coefficients alpha and beta electrons are always > > the same. > > > > > (2) You square because that is the definition of etsecs. It is a > > > somewhat arbitary definition so I am happy to change it. The idea is > > > that these sqr values somehow represent the fractional contribution of > > > a particular SEC to the whole transition. Unfortunately, at least in > > > TD-DFT, this is almost but not exactly true (i.e. these fractional > > > contributions dont add to 1). In fact, this is probably a good unit > > > test to have to make sure that all parsers are doing the same thing. > > > > So we can't really test if they sum up to 1, since they don't :) > > Sorry - I should have been more clear. They almost sum to 1, and so an > assertInside would still be a useful test since if the values sum to > something quite different than 1, there is some problem. However, may > I suggest redefining etsecs to use the original positive or negative > coefficients. The test should use the squared values though. I know we > shouldn't redefine the API in a point release, but I feel no > responsibility towards API attributes that we didn't test rigourously. OK, I understand. > > Another point: as far as I can see, there's no way to force Jaguar to > > print out triplet excited states. > > You're saying that it is possible to do the calculation, but just not > print out the results? No, that is a logical mistake on my part. -- written by Karol Langner Tue Mar 27 17:12:37 CEST 2007 |
|
From: Karol L. <kar...@kn...> - 2007-03-27 14:20:26
|
On Tuesday 27 of March 2007 14:38, Noel O'Boyle wrote: > Sorry - I should have been more clear. They almost sum to 1, and so an > assertInside would still be a useful test since if the values sum to > something quite different than 1, there is some problem. However, may > I suggest redefining etsecs to use the original positive or negative > coefficients. The test should use the squared values though. I know we > shouldn't redefine the API in a point release, but I feel no > responsibility towards API attributes that we didn't test rigourously. Right, etsecs is not defined anywhere yet (neither on the wiki, nor in any comments, I think). I'll change it, then, and add something to the wiki. How should we handle alpha/beta electrons? Should the GAMESS parser only read in the alpha coefficients? Or should the Gaussian parser add beta coefficient even if they re not printed? -- written by Karol Langner Tue Mar 27 17:16:39 CEST 2007 |
|
From: Karol L. <kar...@kn...> - 2007-03-27 14:27:03
|
Another note: jaguar prints the coefficients squared and doubled, just like they were calculated by the Gaussian parser. -- written by Karol Langner Tue Mar 27 17:23:44 CEST 2007 |
|
From: Noel O'B. <bao...@gm...> - 2007-03-27 14:28:34
|
On 27/03/07, Karol Langner <kar...@kn...> wrote: > Another note: jaguar prints the coefficients squared and doubled, just like > they were calculated by the Gaussian parser. Is the original sign included? If not, then it's obviously not possible to use the original 'unsquared' numbers. > -- > written by Karol Langner > Tue Mar 27 17:23:44 CEST 2007 > |
|
From: Karol L. <kar...@kn...> - 2007-03-27 14:42:44
|
On Tuesday 27 of March 2007 16:28, Noel O'Boyle wrote: > On 27/03/07, Karol Langner <kar...@kn...> wrote: > > Another note: jaguar prints the coefficients squared and doubled, just > > like they were calculated by the Gaussian parser. > > Is the original sign included? If not, then it's obviously not > possible to use the original 'unsquared' numbers. I wrote too quickly... jaguar does something more: the original coefficients (read parser-wise the ones offered by GAMESS/Gaussian) are effecctively squared, doubled, square-rooted, and multiplied times the original sign.... that is, they are scaled by a factor of 2.0^0.5. Since alpha/beta electron excitations have the same sign for singlet states, it is possible to reproduce the original number. The only question that remains is what do we want to put in etsecs in the end? Both alpha and beta excitations, even if they are not printed? Karol -- written by Karol Langner Tue Mar 27 17:38:28 CEST 2007 |
|
From: Noel O'B. <bao...@gm...> - 2007-03-27 15:13:38
|
On 27/03/07, Karol Langner <kar...@kn...> wrote: > On Tuesday 27 of March 2007 16:28, Noel O'Boyle wrote: > > On 27/03/07, Karol Langner <kar...@kn...> wrote: > > > Another note: jaguar prints the coefficients squared and doubled, just > > > like they were calculated by the Gaussian parser. > > > > Is the original sign included? If not, then it's obviously not > > possible to use the original 'unsquared' numbers. > > I wrote too quickly... jaguar does something more: the original coefficients > (read parser-wise the ones offered by GAMESS/Gaussian) are effecctively > squared, doubled, square-rooted, and multiplied times the original sign.... > that is, they are scaled by a factor of 2.0^0.5. Since alpha/beta electron > excitations have the same sign for singlet states, it is possible to > reproduce the original number. > > The only question that remains is what do we want to put in etsecs in the end? > Both alpha and beta excitations, even if they are not printed? Seems fine to me BTW, will get to you on parser refactoring as soon as possible. I want to take a quick look over the branch code first... > Karol > > -- > written by Karol Langner > Tue Mar 27 17:38:28 CEST 2007 > |
|
From: Karol L. <kar...@kn...> - 2007-03-27 16:56:38
|
OK, now all the parsers read in the "raw" coefficients - which mean the jaguar parser divides them by sqrt(2.0). I added tests for etenergies and etsecs to check across parsers, basing on the values from the GAMESS test (water for CIS/STO-3G - see my most recent commit). The values of etenergies look good - although I had to give a tolerance of 50cm-1 (is that alot?). 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. Karol -- written by Karol Langner Tue Mar 27 19:45:33 CEST 2007 |
|
From: Karol L. <kar...@kn...> - 2007-03-27 22:22:29
|
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. The sign, however, should influence the transition moments and so also the oscillator strengths. 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. 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? Karol -- written by Karol Langner Wed Mar 28 01:06:11 CEST 2007 |
|
From: Noel O'B. <bao...@gm...> - 2007-03-28 08:36:28
|
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 > |
|
From: Noel O'B. <bao...@gm...> - 2007-03-28 08:45:14
|
On 27/03/07, Karol Langner <kar...@kn...> wrote: > OK, now all the parsers read in the "raw" coefficients - which mean the jaguar > parser divides them by sqrt(2.0). I added tests for etenergies and etsecs to > check across parsers, basing on the values from the GAMESS test (water for > CIS/STO-3G - see my most recent commit). > > The values of etenergies look good - although I had to give a tolerance of > 50cm-1 (is that alot?). Experimentally, we typically use nm, and the conversion from cm-1 to nm (1E7/x = y) has different 'sizes' at different wavelengths. At around 300nm (which is where I expect these transitions are...the typical 'organic chemistry' range), 50cm-1 is less than 1 nm, which is more than acceptable. :-) > 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. As discussed in the other thread, I think we should ignore the signs for the purposes of testing. Although I wonder is this related to alpha/beta? Should both the alpha and beta orbitals for the same transition have the same sign? > Karol > > -- > written by Karol Langner > Tue Mar 27 19:45:33 CEST 2007 > |
|
From: Karol L. <kar...@kn...> - 2007-03-28 12:17:04
|
On Wednesday 28 of March 2007 10:45, Noel O'Boyle 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. > > As discussed in the other thread, I think we should ignore the signs > for the purposes of testing. Although I wonder is this related to > alpha/beta? Should both the alpha and beta orbitals for the same > transition have the same sign? I believe the signs before CI coefficients of alpha/beta determinants should be the same for singlet states. If I'm not mistaken, for triplets they should be reversed. -- written by Karol Langner Wed Mar 28 15:14:48 CEST 2007 |
|
From: Karol L. <kar...@kn...> - 2007-03-28 12:09:51
|
On Wednesday 28 of March 2007 10:36, Noel O'Boyle wrote: > > 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. :-) No, I'm not sure. In any case, I guess then that it makes sense to test only the absolute values of the coefficients, which is what I will do. > >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. :-) Very true :) I'd like to push my limit a little bit further in this topic, though. > > 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)! Point taken. I'm aware comparing timings of Gaussian with other programs is not allowed, what about calculations results themselves? I've seen a few articles that make such comparisons. -- written by Karol Langner Wed Mar 28 15:05:07 CEST 2007 |
|
From: Karol L. <kar...@kn...> - 2007-03-29 19:19:32
|
On Wednesday 28 of March 2007 15:08, Karol Langner wrote: > > >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. :-) > > Very true :) I'd like to push my limit a little bit further in this topic, > though. Well, looks like if I use the SAPS hamiltonian in GAMESS (hamtyp=saps), the oscillator strengths are fine, they agree with Gaussian and Jaguar. That's good news! I uploaded test for both types of hamilatonians. The determinant0-based one is the problematic one - I don't know if it's an error in the program or if it's a different algorithm, but I will inquire. Notice, though, that the oscillator strengths for transitions to triplet states are non-zero in water_cis_dets.out, which is theoretically impossible unless spin-orbit coupling is taken under consideration. Karol -- written by Karol Langner Thu Mar 29 22:14:35 CEST 2007 |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X