Multiwfn official website: http://sobereva.com/multiwfn. Multiwfn forum in Chinese: http://bbs.keinsci.com/wfn
You are not logged in.
Hello,
Your modification on the code is correct.
PS: A more elegant way is adding your function as a new real space function in functions.f90, and link it into user-defined function ("function userfunc(x,y,z)"); in your function code simply set the returned value to zero if it is found to be >=0.5. In this case you can integrate your function in basin analysis module in terms of integrating user-defined function, any modification of basin.f90 is not needed.
Dear Professor Tian,
Thank you for the quick answer! I also wonder, is it possible to plot the second map (or even the first) using the main function 13 (Process grid data), so I would be grateful for your professional feedback
Best wishes,
Alex
Dear Alex,
Main function 13 (grid data processing function) is completely irrelevant to this purpose.
Hello,
In main function 3 of Multiwfn, you can scan any real space function (e.g. ESP) along a given line, and you can manually define coordinate of the two ends of the line. Please check Section 4.3 of Multiwfn manual for example. According to the first map, one end should be set to nuclear position of Se, and another end should be set to the given point "d".
To reproduce the second map, you need to write your own script to generate a batch of points in the scanning path, then you can use the special feature of main function 5 (see "Special case: Calculate data for a set of arbitrarily distributed points" in Section 3.6 of Multiwfn manual) to calculate ESP values at all points at once.
I think this output is easy to understand. It is just the contribution of various angular moments to the NOCV orbitals and pair, so that you can better undstand its nature (Similar to the orbital composition analysis illustrated in Section 4.8 of Multiwfn manual).
Hello,
I cannot reproduce this issue via latest windows version of Multiwfn. The result of Windows version looks reasonable:
---------------- CP 4, Type (3,-1) ----------------
Connected atoms: 2(Cl) -- 1(Cu)
Position (Bohr): -0.000000000000 0.000000000000 1.831754409989
Position (Angstrom): -0.000000000000 0.000000000000 0.969322689737
Density of all electrons: 0.8877069959E-01
Density of Alpha electrons: 0.4419502095E-01MacOS version of Multiwfn is not officially maintained, perhaps the third-part MacOS code or compiler has some compatibility issues. As I am not a MacOS user, I can't help you with this problem, sorry. However, if the MacOS version was compiled yourself, you can search "Connected atoms:" in topology.f90 source code file, and try to modify the corresponding code line to try to address this issue, I think it is not difficult.
Dear Augusta,
Unfortunately it has not been implemented, and I currently do not have a clear plan to implement it because this feature is rarely used by most users.
However, it is not too difficult to modify Multiwfn source code to realize it. I can provide some clues:
The function you mentioned corresponds to "subroutine exctransdip" in excittrans.f90. As you can see, this subroutine calls "subroutine genGTFDmat" in integral.f90 to evaluate dipole moment integrals between all GTFs and store it to a matrix "GTFdipint". If you further look at "subroutine genGTFDmat", you will find it loops each pair of GTFs and calls "subroutine dodipoleint" (in integral.f90) to calculate the dipole moment integral between the GTF pairs.
To analyze transition quadrupole moment instead of the transition dipole moment, you can create a duplicate of "subroutine genGTFDmat" named e.g. "subroutine genGTFQmat" to generate e.g. "GTFQint" matrix (containing quadrupole moment integral between all GTFs), in which "subroutine domultipoleint" (already available in integral.f90) is called to calculate quadrupole integral between GTF pairs. After that, if you let "subroutine exctransdip" call "subroutine genGTFQmat" instead of "subroutine genGTFDmat" and slightly adapt a few related code lines, then transition quadrupole moment between excited states can be obtained.
Best regards,
Tian
Hello,
The plane.txt exported by Multiwfn can be directly imported into e.g. Sigmaplot to plot plane map. I doesn't have any experience in plotting plane map by gnuplot based on external plane data. The meaning of each column of plane.txt is clearly described on screen when Multiwfn exports it, you may consider to write a script to convert the format according to the requirement of the plotting tool you want to use.
Dear Alessio,
1 Aromaticity index is not directly related to pi-pi interaction in benzene dimers. Weak interactions usually have negligible influence on electronic structure and thus aromaticity. To study this the pi-pi interaction, there are many analyses in Multiwfn can be used, such as IGMH visualization analysis (DOI: 10.1002/jcc.26812, DOI: 10.1002/anie.202504895, DOI: 10.1016/B978-0-12-821978-2.00076-3), sobEDA energy decomposition (DOI: 10.1021/acs.jpca.3c04374), superposition of electrostatic potential colored vdW surface maps of monomers (Section 4.A.13 of Multiwfn manual), etc. Please check Section 4.A.5 of Multiwfn manual, which is an overview of methods for studying weak interactions.
By the way, I have a very detailed blog article to discuss pi-pi interaction: http://sobereva.com/737
2 It is relatively easy to characterize aromaticity of benzene in different environments, the HOMA you mentioned can be used, however, its variant HOMAc (J. Org. Chem., 90, 1297 (2025)) performs better and is also supported in Multiwfn, see Section 3.28.7 of manual. In addition, I suggest also using at least one aromaticity descriptor defined based on electronic structure to study aromaticity, the multicenter bond order (MCBO) in Multiwfn is a preferential choice, see Section 3.11.2.
Best regards,
Tian
Dear Prasanta,
The subroutine for loading molden file is "subroutine readmolden" in fileIO.f90 in Multiwfn source code package, you can check this subroutine to understand details. There is no special treatment for the molden file generated by MRCC. As for the order of basis functions in Multiwfn, please search "GTFtype2name" in define.f90 and check relevant arrays and comments.
Best regards,
Tian
Without special reasons, using Fermi-Dirac smearing is recommended.
All useful ways to facilitate SCF convergence have been collectively described and discussed in my blog article: http://sobereva.com/665
Some settings in your file are not reasonable or redundant. For example, ALPHA 0.01, is too aggressive. The settings to tune GAPW calculations are not necessary. Importantly, the cell is very small, and Pt slab it a conductor, considering k-point sampling is indispensable.
Hello,
There is no so-called "extra point charge" in this context. Electron density is calculated directly based on wavefunction according to the equation given in Section 2.6 of Multiwfn manual.
Density=(Check,Transition=1) is incorrect. This keyword requests to generate transition density, which is not needed in the current situation.
Use: CAM-B3LYP/aug-cc-pVTZ TD(root=x) polar, where x is the index of the excited state of interest.
1 l1.exe is an executable file of Gaussian package, it is indispensible when running Gaussian. Because GAUSS_EXEDIR environment variable was not defined, l1.exe cannot be found. The current issue comes from the fact that Gaussian was not properly installed on the machine actually used for Gaussian calculation.
2 You used a wrong input file. The input file for any wavefunction analysis must contain wavefunction information. For Gaussian users, .fch/fchk, .wfn and .wfx file can be used. Please check Section 2.5 of Multiwfn to gain basic knowledge about input file of Multiwfn.
Dear Thangavel,
Yes, some Multiwfn users have similar feedback. But implementation of sobEDA utilizes some special features of Gaussian, which may not be easily realized in ORCA and I don't have enough time to dive into it. However, if anyone is able to successfully create an ORCA-based sobEDA.sh script, it would be great and I definitively will promote it.
Best regards,
Tian
Dear Alessio,
It is suggested to perform full opt for the lowest point of the scan curve to obtain the exact minimum structure of the dimer.
Note that the two benzene molecules are not exactly parallel with each other in the minimum structure of the dimer (though they visually look like very parallel), moreover, bond lengths and dihedrals vary (very slightly) during the complexation process. So, explicitly optimizing the minimum structure is recommended if you need the most accurate binding energy.
Best,
Tian
This will more or less introduce some artificial factors; however, by properly constructing the model dimer system, the artifical effect can be minimzed to a negligible extent. For example, one may need to perform constraint optimization to avoid occurrence of evident steric repulsion between the two fragments in the originally bonded region...
Dear Alessio,
You should use the structure you shown as the initial structure to further optimize the dimer and then perform frequency analysis. Directly performing frequency analysis on a point of relaxed scan trajectory is commonly meaningless.
By the way, using B3LYP-D3(BJ) instead of BLYP-D3(0) is a better choice. Moreover, it is highly deprecated to perform relaxed scan or optimization in combination with counterpoise, because analytical gradient is not available when counterpoise is used, in this case the computational cost of these tasks is very high. 6-311+G* or def-TZVP without counterpoise is absolutely fine enough for present task.
Best regards,
Tian
To realize this aim, the whole molecule must be dissected as two fragments, just like a dimer. You need to properly remove atoms around the bond to be dissected, and some hydrogens usually need to be properly added to saturate the dangling bonds. Sometimes the conformation of the two fragments should be adjusted to avoid occurrence of artificial steric effect between the two fragments.
This is an example of using redim=block, the first and second modes are ignored.
%oldchk=S0_optfreq.chk
#P freq(FCHT,readfc,readFCHT) geom=check
S0->S1 vibronic absorption
0 1
reddim=block
Spectrum=HWHM=250
S1_optfreq.chk
1 2
sobereva wrote:atmraddens.f90 file can be found in the source code package of Multiwfn, in this file you can find "subroutine genatmradpos", which defines radial density for all elements. After replacing the existing data of Tb by the data in sphavgval.txt, you need to recompile Multiwfn to make the modification take effect.
Thank you, I really appreciate the guidance. The Ln complexes are trivalent though. Do I need to generate the reference densities in this Oxidation state, i.e. as Ln(III)? Or in the neutral ground state configuration.
must in the neutral ground state configuration, according to the definition of Hirshfeld method
atmraddens.f90 file can be found in the source code package of Multiwfn, in this file you can find "subroutine genatmradpos", which defines radial density for all elements. After replacing the existing data of Tb by the data in sphavgval.txt, you need to recompile Multiwfn to make the modification take effect.
Calculation of Hirshfeld charges needs electron density of atoms in their isolated states. However, there is no unique way of generating them. I am not sure how ORCA developers generated them and cannot comment on it, what I can say is that the Hirshfeld charge in Multiwfn was implemented in a very rigorous way, and the quality of built-in atomic densities in isolated states has a very high quality (see Section 6.3 of Multiwfn manual for details). So, as long as the wavefunction and structure you provided to Multiwfn are correct, and the commands you inputted in Multiwfn are correct, the Hirshfeld charges computed by Multiwfn must be correct.
BTW: It is suggested to first check if Mulliken charges calculated by Multiwfn and ORCA are the same; if they are the same, that means the wavefunction has been correctly passed to Multiwfn.
Hello,
You can use main function 5 of Multiwfn to calculate grid data for a real space function, then in the post-processing menu, you can choose to export the grid data as the very popular .cub file. See Section 4.5 of Multiwfn manual for examples.
I don't have any experience in using VMD 2.0, and I would still use VMD 1.9.3 in the near future. It should be noted that VMD 2.0 has not been formally released, currently there is only a pre-release version. I will try 2.0 only when the formal version is released.
The steps are seemingly correct.
Please note that when calculating the monomers in Gaussian, "nosymm" keyword should be used to prevent Gaussian from automatically reorientating the system coordinate, otherwise the coordinates of the monomers will finally overlap with each other, and thus the calculated exciton coupling will be completely wrong.
Please only focused on how /auto affects relative energies, e.g. reaction energies and barriers. If this change is indeed significant, perhaps /auto in Gaussian is not well compatible with pseudopotential basis sets, it is suggested to use an all-electron basis set for TM instead and then check if the influence by /auto is in a reasonable range.
Additional question: For single-point energy calculation using an ordinary functional, if I want to compare the performance of the following Pople-type basis sets (6-31g*, 6-311g**, 6-311+g**) with def2-series (which use 5D 7F), would you say that it is more proper to use 6D 10F uniformly for all Pople-type basis sets?
To completely fairly compare accuracy of different basis sets, in principle, it is suggested to use the basis function form employed by the respective original authors of the basis sets. e.g. 6D for Pople series and 5D for def2-series. For angular moment of F or higher, spherical-harmonic form should always be used (note that even for 6-31G, 7F is used by default in Gaussian).
Gaussian by default uses 7F for all basis sets. The difference between 5D and 6D in the case of solvation energy calculation is negligible.
It's true. The effect of this approximation is usually negligible.
If you want to obtain exact total orbital interaction energy, it is suggested to use sobEDA method (J. Phys. Chem. A 2023, 127, 7023−7035). The sum of all NOCV pair contributions may be scaled to the exact value to derive slightly more accurate contribution of each NOCV pair.
Please check Section 3.10.1 of Multiwfn manual, the correspondence is given.