Multiwfn official website: http://sobereva.com/multiwfn. Multiwfn forum in Chinese: http://bbs.keinsci.com/wfn
You are not logged in.
Dear Tian,
Thank you very much.
Sincerely,
Saeed
Dear Tian,
Please suppose a given "WFN" file is at hand. Is there any way to find which "method/basis set" is employed to generate such a file? Usually, this information is not included in a generated "WFN" file.
Sincerely,
Saeed
Dear Tian,
It was received, thank you very very much.
Sincerely,
Saeed
Dear Tian,
Could you please send me a copy of the above-mentioned DOI? I have no access to that.
Sincerely,
Saeed
Thank you very much.
Saeed
Dear Tian,
Your highly valuable and informative comments are so appreciated.
Please let me state that it seems the reference states in these two approaches should be interchanged. Indeed, the reference state in IQA is fragments in their isolated state while in many-body, this reference state is fragments in the fully optimized complex geometry.
Also, please let me ask you if possible provide much evident explanations. Frankly speaking, I cannot well understand your mean or, better, I cannot accept your rationalization while it can be of my wrong understanding.
Sincerely,
Saeed
Dear Tian,
Please suppose a trimer composed of three interacting monomers as, for instance, A...B...C. Also, assume the total electronic energy of this fully optimized trimer is calculated using Gaussian to be X.
You know much better than me based on the Interacting Quantum Atom (IQA), the total electronic energy of this fully optimized trimer is expressed as the sum of electronic energy of any monomer (namely, self atomic energy) plus the sum of pairwise (two-atomic) interaction energies. Using AIMAll, one can easily show that the total electronic energy of this trimer is identical to that obtained by Gaussian (X).
On the other hand, in terms of many-body contribution concept, the total electronic energy of this fully optimized trimer is the sum of electronic energy of monomer plus the sum of pairwise interaction energies (called two-body contribution) and plus an additional term namely three-body contribution. For many cases, three-body contribution is considerable and cannot safely be ignored.
The question is that:
Within IQA and only considering monomeric energies plus pairwise interaction energies, we can reach the value of X but an additional term namely three-body contribution needs to be included if one wants to reach value of X through many-body theory. Could you please let me know why these two approaches function quite different while both are quite reasonable?
Sincerely,
Saeed
Dear Tian,
Thank you very much.
Sincerely,
Saeed
Thank you very much.
Saeed
Dear Tian,
Some codes such as IGMPLOT recommends to use "wfx" instead of "wfn" when user uses PP basis set due to present one or a set of specific atoms in the whole system. Please let me know can we employ "mwfn" file for such cases for which "wfx" needs to be used?
Sincerely,
Saeed
Dear Tian,
If possible please let me ask a short question regarding the sign and value of DelSquar_Rho and ELF at sigma-hole and at Lump.
In a sigma-hole,DelSquar_Rho is essentially positive (where charge density is depleted) and the value of ELF approaches zero. On the other hand, at a Lump (such a lone-pairs of a hetero atom), DelSquar_Rho is essentially negative (where charge density is concentrated) and the value of ELF approaches one (1).
Are these statement correct?
Sincerely,
Saeed
Yes, you are quite right.
Using "density=current" leads both SCF and MP2 densities to be saved in the "chk" file which could simply viewed when "chk" is converted into a readable format such as "fch". But, if such "chk" file is directly loaded into Multiwfn, only SCF density is taken into account for AIM analysis. Consequently, to avoid an additional calculation (out=wfn, density=current leading to wavefunction file with MP2 density, the procedure) recommended by Tian is the best and perfect.
Saeed
Dear Tian,
Too many thanks for your kind attention to guide me with your perfect and very valuable comments.
Sincerely,
Saeed
Dear Tian,
Many many thanks for your highly valuable, professional, and novel comments. I was so enjoyed and learned.
Sincerely,
Saeed
Dear Tian,
Thank you very very much, my nice friend for your highly professional comments I have never been encountered with.
It seems, including or not including "density=current" in the Gaussian input file have not any impact. Indeed, after finishing a (for instance) opt+freq computation using MP2, the generated "chk" file must be converted into "fch" and then follow your instruction.
Sincerely,
Saeed
Dear Tian,
Recently, I studied PnB interaction in O2IPn...NCH systems (Pn= N, P, As, Sb, Bi). While, as many previous experiences, it is expected a satisfactory linear correlation exists between values of Rho at BCP and values of interaction energies, in the case under study, this correlation displays a very poor R*R value. On the other hand, a much more satisfactory correlation is obtained between values of interaction energy and Laplacian of Rho! I also found that the main problem is caused by two heaviest elements Sn and Bi. Indeed, if data associated with these two elements are removed from any regression, the resulted regression is highly improved.
Could you please let me know your highly professional explanation about such a strange and novel observation?
Sincerely,
Saeed
Dear Tian,
I have optimized a molecular structure using "MP2/genecp". Then, corresponding ".chk" file was loaded into Multiwfn to compute QTAIM descriptors at desirable BCP in the hope that the MP2 density is considered by Multiwfn. But, it seems SCF density has been used to perform QTAIM analysis.
As I checked, I have to prepare "wfn" file using "density=current" keyword to reach the goal mentioned.
Please, if possible, let me know if there is another way to force Multiwfn considers MP2 density when I load "chk" file in that and, I have not to perform an additional calculation for generating "wfn" file.
Sincerely,
Saeed
Thank you very much.
Could you also please let me know your comments on 1?
Dear Tian,
1- Many many thanks for the kindness you always kindly gift me making me guide with so valuable comments.
In addition to your valuable comments, please let me know if you know a detailed and evident reference regarding this topic. It seems I should pay much more attention to this issue and, thus, I am looking for the straightforward and complete lecture/text book/etc by which one gets understanding how the small-, medium-, or large-core shell is defined and regarded to an element.
2- It seems the results of DFT-SAPT are not so sensitive to the precision of "grac_shift" value. Do you agree?
3- I would be highly grateful if you introduce me a good lecture/tutorial in which asymptotically behaviour of DFT-SAPT functional is graphically presented (2-D plot of energy vs. distance or something like this) and shows how the "grac_shift" quantity corrects such behaviour (mathematical equations). Previously, I have had such a nice reference but, unfortunately, I cannot find that right now.
Please, in advance, accept my highest apology for taking your so valuable time.
Sincerely,
Saeed
Dear Tian,
When a given atom uses PP basis set, Gaussian takes a specific number of electrons as core electrons. For instance, using aug-cc-pVDZ(+PP) basis set for Iodine atom, Gaussian indicates that 25 electrons out of total 53 electrons are taken as valence electron for Iodine. In consequence, 53-25=28 and, one can conclude that the number of core electrons in Iodine approximated by a PP basis set is 28. The question (which is in my mind for a long time) is that this 28 electron should be regarded as small-core, medium-core, or large-core? Commonly, after computing the number of core-electrons as shown for Iodine, how one reliably should identify small-, medium-, or large-core size regarding the core electrons in a desirable atom?
Moreover, please also let me know how much a given "grac_shift" value in the DFT-SAP should be accurate. Indeed, while some researchers consider only two digits after the decimal point (XX.YY), other ones take 4-5 digits after the decimal point (XX.YYYY or XX.YYYYY) for a given "grac_shift" value.
In advance, many thanks for your kind attention and highly valuable guidance.
Sincerely,
Saeed
Dear Tian,
Too many thanks for your highly valuable and informative comments.
Sincerely,
Saeed
Dear Tian,
1- Please suppose one is going to perform ESP analysis (main function 12) on a "chk" file generated with "genecp" in which some atoms use PP basis sets. Please let me know if ESP analysis is quite correct and reasonable in such cases. If there is any problems, please let me know appropriate technical procedure.
2- Please also let me know what is the difference between "ESP from nuclear charges" and "ESP from electrons". What is the sum and difference of these two quantities referred to, respectively, if such sum or difference is conceptually meaningful?
Sincerely,
Saeed
Dear Tian,
Thank you very very much, my nice friend.
Sincerely,
Saeed
Dear Tian,
As you know much better than me, a DFT-SAPT needs "grac_shift" values for monomers. Please consider the below template employed for a given DFT-SAPT calculation:
memory 55 gb
molecule {
0 1
F 0.00000000 0.00000000 -1.85087700
H 0.00000000 0.00000000 -0.86870700
--
-1 1
Cl 0.00000000 0.00000000 1.03097600
units angstrom
no_reorient
symmetry c1
}
set {
basis aug-cc-pVTZ
df_basis_scf aug-cc-pvtz-jkfit
df_basis_sapt aug-cc-pvtz-ri
scf_type DF
guess sad
freeze_core True
sapt_dft_functional pbe0
sapt_dft_grac_shift_a 0.157
sapt_dft_grac_shift_b 0.215
}
energy('sapt(dft)')
The question is as follows:
the "sapt_dft_grac_shift_a" is always regarded to the monomer whose structure is given first (HF in the present case) and "sapt_dft_grac_shift_b" is always regarded to the monomer whose structure is given second (Cl anion in the present case). Is my statement quite correct?
If no, we should properly define monomer a (for which grac_shift_a is considered) and monomer b (for which grac_shift_b is considered). If possible, considering the given template, please let me know how these two monomers should explicitly and appropriately be defined in two blocks.
Sincerely,
Saeed
Thank you very much.
Dear Tian,
If possible, please let me ask you a short question in SAPT-DFT:
To obtain DFT_Grac_Shift value for two interacting monomers, I am using PBE0/def2-TZVPPD level to optimize monomers geometry (and to obtain HOMO energy) and also to compute Vertical IP value. Then, DFT_Grac_Shift (in a.u.)= VIP(in a.u.)+E_HOMO(in a.u.).
Please let me know if you completely agree with the computational level I employed for mentioned purposes.
Sincerely,
Saeed
Dear Tian,
Too many thanks for your kind attention.
Sincerely,
Saeed
Dear Tian,
There are many nice and highly informative article in your homepage; e.g. "http://sobereva.com/413" or "http://sobereva.com/526", etc. These articles are highly valuable but there is no an ordered and regular list for this articles by which one can easily find the desirable topic. Could you please let me know where I can find all these articles in a regular and integrated manner?
Sincerely,
Saeed
Dear Tian,
Thank you very very much for your kind attention, my nice friend.
Sincerely,
Saeed
Dear Tian,
If possible, please let me ask you a short question regarding Psi4.
Recently, I lost my Psi4 code and had to again install its newest version 1.9.1 through "Conda-Forge". Moreover, I did build a scrath folder for Psi4 in the Home directory and its path was truly included in ".bashrc". When a given Psi4 task is ran, this folder is filled and empty alternately. But, after finishing calculations, this folder remains full and there are several files in it that must be deleted manually, while there was no such problem before. Please also let me state that the problem mentioned above only exists for "CBS-extrapolations" calculations while "SAPT" calculations are never encountered such a problem.
Could you please let me know how I can resolve this problem so that this folder, when a task is over, to be emptied automatically as before?
In advance, too many thanks for your highly valuable guidance.
Sincerely,
Saeed