Hi Tian,

The first point holds correct. This means when I used # B3LYP/6-31G* TD, the dipole moment printed at the end is the ground state dipole moment.

However, when I used # B3LYP/6-31G* TD(root=x) density or # B3LYP/6-31G* TD(root=x) density=rhoci, the dipole moment printed at the end is not the same in the earlier transition electric dipole moment column for the state x. If I can understand your previous reply correctly, then both these dipole moments before  L06 module and at the end should be same for # B3LYP/6-31G* TD(root=x) density or # B3LYP/6-31G* TD(root=x) density=rhoci inputs... right...? but for my calculations these are different. I am using the new revision of G09.

Thanks,
Sayan

Dear Sayan,

Please note that "dipole moment of an excited state", namely <i|-r|i>, is very different "transition dipole moment between ground state and excited state", namely <0|-r|i>.
The "# B3LYP/6-31G* TD(root=x) density" keywords print dipole moment of your selected state at the end of output file, while the data printed prior to L601 is transition dipole moment between ground state and each calculated excited state.

Best,

Tian

The first point holds correct. This means when I used # B3LYP/6-31G* TD, the dipole moment printed at the end is the ground state dipole moment.

However, when I used # B3LYP/6-31G* TD(root=x) density or # B3LYP/6-31G* TD(root=x) density=rhoci, the dipole moment printed at the end is not the same in the earlier transition electric dipole moment column for the state x. If I can understand your previous reply correctly, then both these dipole moments before  L06 module and at the end should be same for # B3LYP/6-31G* TD(root=x) density or # B3LYP/6-31G* TD(root=x) density=rhoci inputs... right...? but for my calculations these are different. I am using the new revision of G09.

Thanks,
Sayan

Several examples:

# B3LYP/6-31G* TD: Dipole moment of ground state at B3LYP/6-31G* level, it is equivalent to "# B3LYP/6-31G*"

# B3LYP/6-31G* TD(root=x) density: Dipole moment of the xth excited state at TD-B3LYP/6-31G* level based on relaxed density

# B3LYP/6-31G* TD(root=x) density=rhoci: Dipole moment of the xth excited state at TD-B3LYP/6-31G* level based on unrelaxed density

# B3LYP/6-31G* TD(root=x) out=wfn: If you are using relatively new revision of G09, or G16, the printed dipole moment is the same as "# B3LYP/6-31G* TD(root=x) density", because "out=wfn" implies "density" keyword. While if you are using much order version, the printed dipole moment is the same as "# B3LYP/6-31G*".

Above rules hold for all kinds of DFT functionals except for the double-hybrid ones.

Best,

Tian

I deleted the previous post because of confusion. So, basically, when density=transition=state of interest is given in the input, the dipole moment printed at the end of Gaussian output is wrong which needs to be divided by sqrt(2). This is true for any DFT functional.

However, If I do a normal TD-DFT without "density=transition=state of interest " statement, then what dipole moment is printed at the end of output...? is it the transition dipole moment for the first excited state (as in Gaussian the default is the first excited state) or is it the ground state dipole moment...? I am dealing with B3LYP, CAM-B3LYP and wB97X functional and I noticed that for wB97X, TDM printed at the end is exactly equal to my first excited state TDM, whereas for B3LYP/CAM-B3LYP those values are different.

So, I want to know what is that dipole moment printed at the end of Gaussian output, when you do a normal TD-DFT calculation...? and whether it's value is correct or not..? Hope you have understood my confusion. Thanks.

Best,
Sayan

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

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

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

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

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

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

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

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.

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

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