TrEsp Charges using ORCA

sayan307 · 2019-01-25 15:15:00

Hi Tian,

Sorry to disturb you again. At the moment I can successfully calculate the TrEsp charges using Gaussian and Multiwfn. However, I need to calculate the TrEsp charges using ORCA+Multiwfn. I know multiwfn can handle .molden input which can be generated from ORCA directly. However, I need to know about the input file of orca to calculate the transition density for my state of interest. Just like in Gaussian, you showed in your example density=transition=state of interest.
So, do you know any similar kind of thing is available in ORCA.. as in orca we need to mention nroot for total no of the excited state, but how can I extract the state of interest...? Do you have any solution for this...?

Thanks.

Regards,
Sayan

Last edited by sayan307 (2019-07-15 10:18:00)

sobereva · 2019-01-27 14:07:44

Dear Sayan Maity,

It seems that ORCA is unable to directly export natural orbitals corresponding to transition density matrix (TDM), therefore, you have to use Multiwfn to generate these orbitals first based on MOs and configuration coefficients of TDDFT task of ORCA.

Initially, carry out a typical TDDFT calculation via keywords such as follows (see beginning of Section 3.21 for detail):
! PBE0 def2-SVP nopop
%tddft
nroots 5
tprint 1E-8
end

Then use orca_2mkl to convert the resulting .gbw file to .molden.input file.

Then boot up Multiwfn and load the .molden.input file, input below commands
18
9 // Generate and export transition density matrix
1 // Generate transition density matrix between ground state and excited state
2 // Assume that you want to analyze S0-S2 excitation
y // Symmetrize the newly generated TDM
y // Export TDM.fch in current folder, whose "Total SCF Density" field will correspond to S0-S2 TDM

Now, reboot Multiwfn and input
TDM.fch
200
16 // Generate natural orbitals based on the density matrix in .fch/.fchk file
SCF // Diagonalize the "Total SCF Density" field in the .fch file to generate natural orbitals
y
Now you have new.molden in current folder, it contains natural orbitals corresponding to S0->S2 TDM. By using this file as input file of Multiwfn, you can then calculate TrEsp as usual.

Although above steps are seemingly lengthy, you can properly write a small shell script to automate the calculation.

Notice that TDA approximation is employed during ORCA calculation in above example. Although you can disable this treatment, the TDM generated by Multiwfn may not be always reasonable, because current version of ORCA doesn't print coefficients of excitation and de-excitation configurations separately.

Best regards,

Tian

sayan307 · 2019-01-27 15:54:49

Hi Tian,

Thanks. Using your procedure I can calculate TrEsp charges. However, as you said TDM calculated by multiwfn may not be always reasonable using the latest version of ORCA. At the moment, I am using ORCA 4.0.1.2 which is the quite latest version. So, so should I use some older versions of ORCA (the older version installed in our machine is 2.9.1) to calculate TrEsp charges or this version is okay...?

Thanks.

Best,
Sayan

sobereva · 2019-01-27 21:30:07

Dear Sayan,

The latest version currently is ORCA 4.1. I only used ORCA 3.0.x, 4.0.x and 4.1, all of them do not print excitation and de-excitation coefficients separately, I think the same is also true for the very old version 2.9.1. I hope this annoying problem could be recognized and fixed by Prof. Neese in the future releases ;-)

Best regards,

Tian

sayan307 · 2019-01-27 21:59:44

Hi Tian,

Now, this makes me confused. So if it doesn't print those coefficients at all then how these TDM and corresponding TrEsp charges are calculated ....? This only means these TrEsp charges are wrong...isn't it...? So, basically, I can't deal with ORCA to calculate TrEsp charges at moment.. right...?

Best,
Sayan

sobereva · 2019-01-28 07:03:22

Dear Sayan,

Please note this paragraph at the beginning of Multiwfn 3.6(dev) manual:

Note: It is also possible to use ORCA TDDFT/TDHF output file, but the analysis result may be reliable!!! Because in TD task, ORCA only prints configuration contributions but does not print configuration coefficients, so Multiwfn automatically generates the latter by computing square root of the former. This treatment looks reasonable, however when de-excitation is significant, the configuration coefficients yielded in this manner must be nonsense, because in TD task output file, de-excitation contribution and excitation contribution of an orbital pair are summed up and outputted as a single term.

That is, for standard TDDFT, the configuration coefficients utilized by Multiwfn is approximated, because ORCA doesn't print them explicitly. While when TDA-DFT (i.e. TDDFT with TDA approximation) is used, the configuration coefficients can be exactly derived from output of ORCA, and thus the analysis result of Multiwfn is always correct.

Best,

Tian

sayan307 · 2019-01-28 09:21:34

Hi Tian,

I understood. The analysis of TD-DFT under TDA is absolutely perfect by Multiwfn. I did a test for a small system like 4-nitroaniline (16 atoms) and I am getting quite reasonable results for the TrEsp charge. However, when I am dealing with my real system Chlorophyll A (82 atoms), I am getting the segmentation fault error during the generation of natural orbital from TDM.fch file. I successfully generate TDM.fch from my ORCA outputs, but when I am using it in the second step to generate natural orbital (NO), some weird error like:

Generating NOs, please wait...
forrtl: severe (174): SIGSEGV, segmentation fault occurred
Image PC Routine Line Source
Multiwfn 0000000001426655 Unknown Unknown Unknown

So, how do I deal with this error ...? Thanks for your quick reply though ..!!

Best,
Sayan

Last edited by sayan307 (2019-02-01 23:30:50)

sobereva · 2019-01-28 10:35:10

Please make sure that you have configured your Linux system according to Section 2.1.2 of the manual. If the problem is still unable to be solved, please use Windows version instead.

sayan307 · 2019-01-28 13:36:36

Hi Tian,

Again found a problem regarding the TrEsp charge calculation. In principle, the transition dipole moment (TDM) obtained from the Gaussian/ORCA output should be close enough compare to TrEsP_TDM (dipole moment calculated manually by putting TrEsp charges corresponding to each atom and then measure dipole using VMD). But, this not happening using the TrEsp charges calculated by Multiwfn. The TrEsp_TDM and TDM from obtained from Gaussian/ORCA are different. This should not happen in principle. I was comparing my data with the original TrEsp paper J. Phys. Chem. B 2006, 110, 34, 17268-17281, where I found that TrEsp_TDM and transition dipole moment from ORCA/GAUSSIAN output is almost the same. I don't know how did you fit the transition density or maybe I am doing something wrong.

Hope you understood my doubt.

Thanks.

Best,
Sayan

sobereva · 2019-01-28 20:25:18

Dear Sayan,

Thank you for reporting this problem, the source of this problem is that Gaussian utilizes a very weird way to symmetry the transition density matrix before exporting natural orbitals to .wfn file, and the finally resulting TrEsp charges should be manually divided by sqrt(2) to fix this issue. By the way, due to the same reason, when transition=density=x is used, the dipole moment printed at the end of Gaussian output file is also not the correct transition dipole moment between ground state and the xth excited state, it should be divided by sqrt(2) too.

I just updated the Multiwfn 3.6(dev) program and manual, please download them. In the updated Section 4.A.9 of manual, I do not only describe how to correctly evaluate the TrEsp charges but also mentioned how to verify if the result is correct.

Best regards,

Tian

sayan307 · 2019-01-28 21:08:24

Hi Tian,

Thanx for fixing the bug. The issue of 1/sqrt(2) was always a problem in the earlier version of Gaussian as Prof. **** (one of the Gaussian developer) was discussing this issue earlier. However, she has suggested that this problem has been solved. (but I don't know in which version. I have done my calculation with g09 and found this problem. If you have g16, you can try and let me know).

The dipole moment printed at the end by describing the input transition=density=x, first I also thought that this is the right transition dipole, that's why I was sure that the TrEsp_TDM and this dipole moment are in correct order:). Then I noticed that in the transition electric dipole moment column the results are different. That's why I was not sure whether the last printed dipole moment was transition dipole moment or ground state dipole moment as nothing was clear to me.

Now, I can guess that professor was talking about this issue and I think this problem is not there in the latest version of Gaussian.

Best,
Sayan

Last edited by sayan307 (2019-01-29 18:59:58)

sayan307 · 2019-01-28 21:25:50

Hi Tian,

Also what about the ORCA output...? Because the ORCA outputs are not also providing the TrEsp_TDM and the TDM calculated from the output in the same order...!! Thanks.

Best,
Sayan

sobereva · 2019-01-28 21:54:15

sayan307 wrote:

Hi Tian,
Also what about the ORCA output...? Because the ORCA outputs are not also providing the TrEsp_TDM and the TDM calculated from the output in the same order...!! Thanks.
Best,
Sayan

If you are using the Multiwfn I updated today, still using exactly the same procedure as I described in #2, the result will be correct. (In old version, the symmetrization method of TDM in Multiwfn follows the convention of Gaussian, while in the latest version, the default symmetrization method has been changed to reasonable way, namely TDM(i,j)=[TDM(i,j)+TDM(j,i)]/2, therefore the problem of sqrt(2) no longer needs to be concerned)

Tian

sobereva · 2019-01-28 21:57:23

sayan307 wrote:

Hi Tian,
Thanx for fixing the bug. The issue of 1/sqrt(2) was always a problem in the earlier version of Gaussian as Prof. **** (one of the Gaussian developer) was discussing this issue earlier. However, she has suggested that this problem has been solved. (but I don't know in which version. I have done my calculation with g09 and found this problem. If have g16 you can try and let me know).
...

I have tried G16 A.03, which is the latest version that I have, this problem in Gaussian still exists...

sayan307 · 2019-01-29 06:08:45

Hi Tian,

That sounds too bad that Gaussian16 still has this problem. I think better you can contact the Gaussian developers to deal with this issue. Thanks.

Best,
Sayan

sobereva · 2019-01-29 06:25:37

sayan307 wrote:

Hi Tian,
That sounds too bad that Gaussian16 still has this problem. I think better you can contact the Gaussian developers to deal with this issue. Thanks.
Best,
Sayan

I think Gaussian staffs must already know this "problem". I guess there must be some reasons that they do not want to fix it. (I don't have Gaussian 16 B.01 in hand, I am not sure if this problem have been fixed in this latest revision)

There are also other well-known historic issues in Gaussian, such as the sign of hyperpolarizability is reversed, however they have not been fixed until now.

sayan307 · 2019-01-29 11:17:22

Hi Tian,

In the Gaussian output the transition dipole moment in the transition electric dipole moments columns, the values are correctly printed (if you multiply with 2.54 then you will get the correct value in Debye). Then how they made this mistake at the end of the output. Are you sure that this is the transition dipole moment for a specific transition or something else...?

Best,
Sayan

sobereva · 2019-01-29 15:18:36

Dear Sayan,

The information of various kinds of transition moments printed before L601 module should be correct, it seems that the symmetrized TDM was generated in L601 module. The dipole moment printed at the end of output file, as well as the natural orbitals generated by out=wfn, are actually yielded by L601.

Best,

Tian

sayan307 · 2019-01-29 17:01:28

Hi Tian,

ORCA can provide transition density file for a specific transition in .cube file format. So, can multiwfn use that transition density cube file to calculate TrEsP charge...? Or you always need a natural orbital file to calculate TrEsp, I think N.O.s are derived from the transition density isn't it ...?

Also, as ORCA didn't provide transition dipole moment in the output, I used multiwfn to calculate that and the values are absolutely fine. However, here is a discussion that the transition dipole moment from the ORCA cube file, there was a missing factor of sqrt(2), similar kind of discussion like gaussian https://orcaforum.kofo.mpg.de/viewtopic … ity#p16931

Please read the last comment. So, did ORCA developer fixed this factor in the latest versions...?

Best,
Sayan

sobereva · 2019-01-29 17:21:48

Dear Sayan,

I don't have any experience of dealing with the transition density directly outputted by ORCA, currently I use Gaussian much more frequently than ORCA. Using transition density grid data to evaluate corresponding ESP is in principle viable, but the cost must be extremely high, therefore I don't intend to implement this.

About the sqrt(2) problem of ORCA, I am not sure and I didn't notice this issue before. Because recently I am fairly busy, I am sorry that I don't have time to dive into it.

Best regards,

Tian

sayan307 · 2019-01-29 18:07:41

Hi Tian,

Thanks for your reply. Also, I am requesting you to delete that professor name from the quote you replied in #14. I mistakenly posted that name. I should not post any arbitrary name in such an open discussion. Hope you understood.

Thanks.

Sayan

sobereva · 2019-01-29 18:36:41

sayan307 wrote:

Hi Tian,
Thanks for your reply. Also, I am requesting you to delete that professor name from the quote you replied in #14. I mistakenly posted that name. I should not post any arbitrary name in such an open discussion. Hope you understood.
Thanks.
Sayan

OK, I have hidden the name.

sayan307 · 2019-01-29 19:41:00

Hi Tian,

Again, I just downloaded the multiwfn3.6(dev) source code and binary for Linux and used them to calculate the TrEsp, but alas..!! it is giving the old charge no sqrt(2) is multiplied in the value. I think you have mistakenly uploaded the old versions. Please upload the new versions. Also, I didn't find any discussion to check whether these charges are correct or not in the manual.

Also, regarding the Skill-1 (cubegen utility), I think this is only applicable for binary executable at the moment right...? As the description to set the path of gaussian cubegen is in the settings.ini file, which you have only provided for binary executable, not for the source code.

Thanks,

Best,
Sayan

sobereva · 2019-01-29 21:51:43

Dear Sayan,

Both the program and manual on the Multiwfn website are correct. Below are screenshots of currently latest version of manual. Please make sure you can find "2019-Jan-29" at the first page of the manual. You need to manually divide the data by sqrt(2), as explicitly mentioned in the latest manual.

What the Multiwfn invokes is binary version of cubegen. I cannot provide its source code along with Multiwfn because it releases as a part of Gaussian and thus is not free of charge.

Best,

Tian

sayan307 · 2019-01-29 22:20:24

sobereva wrote:

sayan307 wrote:
Hi Tian,
Also what about the ORCA output...? Because the ORCA outputs are not also providing the TrEsp_TDM and the TDM calculated from the output in the same order...!! Thanks.
Best,
Sayan
If you are using the Multiwfn I updated today, still using exactly the same procedure as I described in #2, the result will be correct. (In old version, the symmetrization method of TDM in Multiwfn follows the convention of Gaussian, while in the latest version, the default symmetrization method has been changed to reasonable way, namely TDM(i,j)=[TDM(i,j)+TDM(j,i)]/2, therefore the problem of sqrt(2) no longer needs to be concerned)
Tian

Here, you mentioned that you have changed the code which means the code will produce the correct charges. That's why I thought that now I don't need to correct the charge manually. However, If it is not done yet, I can rescale the charge manually. But, I think you will put this sqrt(2) factor inside the code also which may not be a big task for you I guess. I hope in the later release you will do that so that we can take the TrEsp charges directly from the output.

Thanks.

Regards,
Sayan

sobereva · 2019-01-29 22:41:16

Dear Sayan,

I strongly believe it is inappropriate to put the sqrt(2) directly in the Multiwfn code. The ESP fitting module of Multiwfn is designed as a general module, not specific for Gaussian users. As developer, I don't know where the natural orbitals provided by the users actually come from. If one uses natural orbitals corresponding to correct TDM while the result is always automatically divided by sqrt(2) when printing, clearly it is a very terrible thing. In addition, it is also possible that one day the Gaussian staffs fix the sqrt(2) problem. Therefore, I believe properly treating the sqrt(2) is responsibility of users, what should I do is stressing this potential issue explicitly at proper place of manual.

Best,

Tian

sayan307 · 2019-01-30 05:33:14

Hi Tian,

Okay, I understood that you don't want to directly put sqrt(2) inside the Multiwfn as you believe that in future Gaussian group would fix this corresponding the natural transition orbitals.

However, you showed in the manual that using the cubegen utility of Gaussian the charges can be directly calculated no sqrt(2) is need as you manually symmetrized the TDM by 2 instead of sqrt(2). I didn't configure properly this cubegen utility of Gaussian and multiwfn in my machine by just setting the cubegen path in the settings.ini file of the latest Multiwfn3.6 binary executables. Maybe I need to play around it a little bit.

However, what about ORCA, because you said that you are generating natural transition orbital by using correct symmetrized TDM manually, so in principle, the natural transition orbitals should be correct. But, still, the TrEsp charges calculated by ORCA is wrong. Is it the terrible thing you tried describe....? So, for ORCA after using the correct TDM, again I need to divide by sqrt(2) to get proper charges.. right.? But that's weird. This clearly suggests the TDM generated from ORCA is wrong which you think is correct. Similar kind of discussion was going on in the previous link what I sent you regarding the transition dipole moment using ORCA. https://orcaforum.kofo.mpg.de/viewtopic … ity#p16931

Thanks,

Best,
Sayan

Last edited by sayan307 (2019-01-30 06:01:00)

sobereva · 2019-01-30 07:59:51

Dear Sayan,

Not only because future version of Gaussian may fix this problem, but also the users may use other quantum chemistry package to yield the natural orbitals corresponding to TDM, in that case the TDM may be the correct one.

I am not sure why cubegen doesn't work for you, please carefully check prompt on screen.

I didn't mention that the TDM directly given by ORCA must have been symmetrized in correct way, in fact I never checked this point. For ORCA users, I can only garantee that the procedure I described at #2 works reasonably for latest version of Multiwfn and ORCA. If you find the TDM and correspondingly resulting natural orbitals *directly* generated by ORCA are also problematic due to the same reason as Gaussian, please also manually fix the sqrt(2) problem.

PS: I suggest not to use the word "natural transition orbital" in discussion of present problem, because it commonly refers to the well-known NTO used in excitation analysis, and it is very different to the common sense of "natural orbitals corresponding to TDM" (i.e. natural orbitals generated by diagonalization of symmetrized TDM).

Best wishes,

Tian

sayan307 · 2019-01-31 17:39:57

Hi,

Now, I can calculate the correct TrEsp charge using ORCA, as I have noticed that you have provided two options whether the user would do symmetrization of TDM with 2 or sqrt(2). Thanks again for clarifying all the doubts regarding this TrEsp calculations. One last point, you have described in the manual
3 // Transition electric

but, in the prompt, it's showing
3 Transition electronic (Mainly used for deriving TrEsp charges)

So, this electric and electronic have the same meaning in this context...?

Best,
Sayan

sobereva · 2019-01-31 18:22:22

sayan307 wrote:

Hi,
Now, I can calculate the correct TrEsp charge using ORCA, as I have noticed that you have provided two options whether the user would do symmetrization of TDM with 2 or sqrt(2). Thanks again for clarifying all the doubts regarding this TrEsp calculations. One last point, you have described in the manual
3 // Transition electric
but, in the prompt, it's showing
3 Transition electronic (Mainly used for deriving TrEsp charges)
So, this electric and electronic have the same meaning in this context...?
Best,
Sayan

Dear Sayan,

Yes, I didn't distinguish these two words in this context.

Best,

Tian

Multiwfn forum

#1 2019-01-25 15:15:00

TrEsp Charges using ORCA

#2 2019-01-27 14:07:44

Re: TrEsp Charges using ORCA

#3 2019-01-27 15:54:49

Re: TrEsp Charges using ORCA

#4 2019-01-27 21:30:07

Re: TrEsp Charges using ORCA

#5 2019-01-27 21:59:44

Re: TrEsp Charges using ORCA

#6 2019-01-28 07:03:22

Re: TrEsp Charges using ORCA

#7 2019-01-28 09:21:34

Re: TrEsp Charges using ORCA

#8 2019-01-28 10:35:10

Re: TrEsp Charges using ORCA

#9 2019-01-28 13:36:36

Re: TrEsp Charges using ORCA

#10 2019-01-28 20:25:18

Re: TrEsp Charges using ORCA

#11 2019-01-28 21:08:24

Re: TrEsp Charges using ORCA

#12 2019-01-28 21:25:50

Re: TrEsp Charges using ORCA

#13 2019-01-28 21:54:15

Re: TrEsp Charges using ORCA

#14 2019-01-28 21:57:23

Re: TrEsp Charges using ORCA

#15 2019-01-29 06:08:45

Re: TrEsp Charges using ORCA

#16 2019-01-29 06:25:37

Re: TrEsp Charges using ORCA

#17 2019-01-29 11:17:22

Re: TrEsp Charges using ORCA

#18 2019-01-29 15:18:36

Re: TrEsp Charges using ORCA

#19 2019-01-29 17:01:28

Re: TrEsp Charges using ORCA

#20 2019-01-29 17:21:48

Re: TrEsp Charges using ORCA

#21 2019-01-29 18:07:41

Re: TrEsp Charges using ORCA

#22 2019-01-29 18:36:41

Re: TrEsp Charges using ORCA

#23 2019-01-29 19:41:00

Re: TrEsp Charges using ORCA

#24 2019-01-29 21:51:43

Re: TrEsp Charges using ORCA

#25 2019-01-29 22:20:24

Re: TrEsp Charges using ORCA

#26 2019-01-29 22:41:16

Re: TrEsp Charges using ORCA

#27 2019-01-30 05:33:14

Re: TrEsp Charges using ORCA

#28 2019-01-30 07:59:51

Re: TrEsp Charges using ORCA

#29 2019-01-31 17:39:57

Re: TrEsp Charges using ORCA

#30 2019-01-31 18:22:22

Re: TrEsp Charges using ORCA

Board footer