Multiwfn forum

Hi Tian,

Thanks for your reply. Could you please let me know a little bit about the  "special treatments" which are applied to the .molden file...? Is it just a file formatting treatment or something related to electronic properties...?  Then it will be clear to me.

Regards,
Sayan

Hi Tian,

Thanks. Now it works...!! I was giving the wrong input during the calculation.

Regarding, this two-stage fitting you said for MD simulation purpose it is better. For my work, I want to impose my charges on each atom of a molecule and then calculate the couplings along the trajectory, so should I use two-stage fitting or one stage fitting....?

Also, in the two-stage fitting, I think these chgcons.txt/eqvcons.txt inputs are not taking into consideration.

Another doubt, I have realized that Gaussian itself can calculate the  ESP fitted charges using CHELPG method. So, can Gaussian directly calculate the TrESP or transition Mulliken charges if I requested density=transition=1  pop=(chelpg, dipole)...?  The printed charges at the end are the transition charges or ground state charges...?

Best,
Sayan

Hi Tian,

That was my doubt...!!

However, I am facing a problem regarding the symmetry of a molecule.  I have a perfectly symmetric molecule, but when I am calculating the  ESP fitting charges for the ground state, excited state, and TrESP, the charges are not equivalent for the symmetric atoms.  So, should I have to use eqvcons.txt, in the  RESP module in order to get symmetrical charges distribution....?  If this is the case then why it is not automatically taking the identical symmetrical charge distribution for identical molecules as I am using the optimized geometry. So, every time for symmetrical atoms should I have to take this eqvcons.txt into account as in MD simulation this creates problem...?

Also, is it true if the transition density is constant irrespective of charge distribution for a non-symmetrical molecule, then the excitonic coupling should also be constant...?

Best,
Sayan

Hi Tian,

Thanks for your clarification. Also one thing, when the natural orbitals are generated from the .fchk file, no symmetrization were done, so symmetrization of density matrix is only required for TrESP charges calculation...right ...?   

During the ESP fitting charges which option I should choose if I want to compare the dipole moment printed at the end for ground state calculation...?

1. Nuclear + Electronic
2. Electronic only

Best,
Sayan

Hi Tian,

The .molden.input from ORCA and .fchk from Gaussian have the features used as an input in Multiwfn... right....?

Also, if I can understand correctly... for the  Mulliken transition charge calculation the transition density matrix needs not to be symmetrized what is essential for TrESP calculation, that's why I don't need to worry about this sqrt(2) problem.... right ...?

Best,
Sayan

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

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

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

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

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

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