Multiwfn official website: http://sobereva.com/multiwfn. Multiwfn forum in Chinese: http://bbs.keinsci.com/wfn
You are not logged in.
Dear Lorenzo,
In your way the wavefunction of excited state cannot be directly passed to Multiwfn. Although density matrix of excited state was written into .chk file due to "density=current", Multiwfn doesn't directly utilize it because by default Multiwfn only loads orbital information from the inputted wavefunction file.
The most convenient way of performing this analysis for an excited state in Multiwfn is using "out=wfn" keyword and specify the .wfn file to be exported at the end of Gaussian input file. After TDDFT calculation, the natural orbitals of the excited state chosen by "root" (default is 1) will be generated and exported to the .wfn file, which can be used as input file of Multiwfn.
By the way, using "nstates=1" is deprecated. Due to the TDDFT solving algorithm reason, when you are interest in excited state i, "nstates" should be set to at least i+2 to guarantee enough solving accuracy for state i.
They are realized via Multiwfn, unfortunately, this function is currently not possible for ORCA users. Please check this post for reason: http://sobereva.com/wfnbbs/viewtopic.php?id=1847
After my very long time hard work, now I am very pleased to announce that online manual of Multiwfn is available!
It can be accessed at: http://sobereva.com/multiwfn/manual
I believe this online manual is significantly more user-friendly and search-engine-friendly and AI-friendly than the pdf manual, which will help more chemists recognize the important value of Multiwfn and get started using it.
The online and pdf versions will be updated simultaneously in the future.
Hello,
Please always use VMD 1.9.3, it is most stable and robust, I only use this version currently. NEVER use non-formal version of VMD 1.9.4, which brings great troubles.
You should first learn basic knowledge about using most popular quantum chemistry codes (suitable for isolated molecules and clusters), such as Gaussian and ORCA; or using the very popular first-principes code CP2K (suitable for periodic systems). To perform wavefunction analysis by Multiwfn, you need to use these computational codes to generate wavefunction file first, please check beginning part of Chapter 4 of Multiwfn manual, where the way of preparing wavefunction files is described.
Then, you can use proper functions of Multiwfn to study these real space functions. There is no unique way to study them, for example, you can plot them as a curve/plane/isosurface map, perform topology or basin analysis on them. If you focus on topology properties, I think you should first check examples in Section 4.2 of manual, where I provided many examples of using the topology analysis module of Multiwfn.
The Multiwfn manual is extremely detailed, you can find very rich information (introduction of theoretical backgrounds, usage of different functions, practical examples and hints) from it.
I don't find any issue when running sobEDA based on your provided files:
[root@localhost tmp]# /sob/sobEDA.sh
Number of fragments: 2
Charge and spin multiplicity of fragment 1: 0 1
Indices of atoms in fragment 1: 1-174
Generating Gaussian input file of fragment 1 via Multiwfn (fragment1.gjf)
Running: g16 < fragment1.gjf &> fragment1.out
Finished successfully!
Running: formchk fragment1.chk fragment1.fch
Energy components of fragment 1:
E_tot = -3184.52500742 Hartree
E_T = 3150.891484 Hartree
E_els = -5871.6998116493 Hartree
E_x = -444.739577 Hartree
E_c = -18.812155 Hartree
E_disp = -0.1649477707 Hartree
Charge and spin multiplicity of fragment 2: 0 1
Indices of atoms in fragment 2: 175-348
Generating Gaussian input file of fragment 2 via Multiwfn (fragment2.gjf)
Running: g16 < fragment2.gjf &> fragment2.out
Finished successfully!
Running: formchk fragment2.chk fragment2.fch
Energy components of fragment 2:
E_tot = -3184.52444626 Hartree
E_T = 3150.895629 Hartree
E_els = -5871.6978289973 Hartree
E_x = -444.744350 Hartree
E_c = -18.812861 Hartree
E_disp = -0.1650352627 Hartree
Generating fch file of promolecular state via Multiwfn (promol.fch)
Running: unfchk promol.fch promol.chk
Generating Gaussian input file of promolecular state via Multiwfn (promol.gjf)
Running: g16 < promol.gjf &> promol.out
Finished successfully!
Energy components of promolecular state:
E_tot = -6369.31107284 Hartree
E_T = 6301.787113 Hartree
E_els = -11743.4401950744 Hartree
E_x = -889.547894 Hartree
E_c = -37.688016 Hartree
E_disp = -0.4220807656 Hartree
Generating Gaussian input file of final state (final.gjf)
Running: g16 < final.gjf &> final.out
Finished successfully!
Energy components of final state:
E_tot = -6369.16498157 Hartree
E_T = 6301.596663 Hartree
E_els = -11743.1587828044 Hartree
E_x = -889.492754 Hartree
E_c = -37.688027 Hartree
E_disp = -0.4220807656 Hartree
Frozen state energy: -6369.11343980710 Hartree
*************************
***** Final results *****
*************************
Total interaction energy: -72.49 kcal/mol
Physical components of interaction energy derived by sobEDA:
Electrostatic (E_els): -26.70 kcal/mol
Exchange (E_x): -40.14 kcal/mol
Pauli repulsion (E_rep): 124.02 kcal/mol
Exchange-repulsion (E_xrep = E_x + E_rep): 83.88 kcal/mol
Orbital (E_orb): -32.34 kcal/mol
DFT correlation (E_DFTc): -39.53 kcal/mol
Dispersion correction (E_dc): -57.79 kcal/mol
Coulomb correlation (E_c = E_DFTc + E_dc): -97.33 kcal/mol
Please do not forget to cite original paper of Multiwfn program and sobEDA method in your work!Please make sure that, as I mentioned previously, unfchk command is available (i.e. can be invoked by sobEDA.sh). This is independent on your input files, but running environment. If unfchk command is indeed available, please run "export GAUSS_MEMDEF=4GB" before running sobEDA.sh, so that GAUSS_MEMDEF environment variable is increased to a large enough value. This value determines the maximum memory that unfchk/formchk can be utilized, the default value is too small for converting large systems.
If you are pretty sure that this issue doesn't come from the unfchk/formchk step, you can send the input files to my E-mail (rather than directly paste here), I will try to run.
Hello,
I don't know what "used my ORCA output as molden input" means. For ORCA users, both molden input file and ORCA output file are needed.
I also cannot answer your question without your ORCA input file. Please make sure that you have properly set "tprint" as mentioned in Section 3.21.A.3 of Multiwfn manual, otherwise many nonnegligible configurations will be ignored and this issue may thus happens.
From your screenshot, I can only find you defined two rather than three fragments. Some atoms, such as atom 10, is missing. This results in the sum of the contributions from all fragments not equaling 100%.
Anyway, you need to eliminate the error that unfchk command cannot be found. Without chk-fch file conversion, sobEDA task cannot run successfully.
What I can see from your screenshot is that "unfchk" command is not available, it is a utility in Gaussian installation folder. You must properly install Gaussian and configure your running envirnoment so that sobEDA.sh can successfully call "unfchk" command.
I don't know what the first screenshot corresponds to, it is seemingly irelevant to sobEDA analysis. opt freq scf=xqc keywords should not be included in this analysis.
PS (not related to sobEDA anlysis): Using scf=xqc is highly deprecated to be used as a default keyword, the QC stage is quite slow and easy to converge to unstable wavefunction. Also, =noraman is a well-known fully redundant option, Gaussian doesn't calculate Raman activity during frequency analysis by default when DFT is used.
Dear Alessio,
This question involves many technique points, I will explain in turn below.
* Multiwfn is able to plot ESP 2D map in any plane, including the plane you mentioned, see Section 4.4.4 of Multiwfn manual for example, and the grid data of the entire plane can be exported to a .txt file in the post-processing menu.
* Multiwfn is unable to directly plot 2D map in the plane for a real space function only within vdW surface projection region, however there is workaround. You can use Multiwfn to generate an image file of 2D map of ESP in the entire plane that 3.25 Å from the molecule, and generate an image file representing vdW surface in the molecular plane (i.e. rho=0.001 a.u. contour line. See the bold blue line in the example in Section 4.4.4). Then, use photoshop or AI tool (gemini, etc.) to remove content of the first map that outside the contour line of the second map.
* I don't know how ESPmin and ESPmax were exactly defined in that paper. I would like to mention that Multiwfn is not only able to determine minima and maxima of any selected real space function over the entire 3D molecular vdW surface, but also able to determine those on a contour line of a given real space function in a 2D plane, see Section "4.4.12 Showing extrema of a function on contour line" of manual for example. Perhaps you can achieve your aim by properly using these features.
* Electric field is a vector rather than a scalar field. However, user-defined function 103 in Multiwfn directly corresponds to magnitude of electric field (norm of the vector), see corresponding part of Section 2.6 of manual. You can use similar way as mentioned above to study electric field magnitude.
Best regards,
Tian
These are new functions added into Multiwfn 2026.10.1:
The dual descriptor and Fukui function forms proposed specifically for open-shell cases with/without degeneracy in frontier MOs by Martínez Araya in Chem. Phys. Lett., 506, 104 (2011) now can be calculated in subfunction 12 of conceptual DFT module (main function 22). See Section 3.25.4.2 for introduction and Section 4.22.3.3 for example.
Three variants of MBIS population analysis, namely constrained MBIS (cMBIS), elliptical MBIS (EMBIS), asymmetric elliptical MBIS (AEMBIS), have been implemented as subfunctions 21, 22, 23 in main function 7, respectively. See Section 3.9.19 of Multiwfn manual for relevant information. These codes were contributed by the method authors, Prof. Frank Jensen.
The dual delocalization descriptor (DDD) proposed in Phys. Chem. Chem. Phys., 28, 19133 (2026) by Samir Kenouche has been implemented in conceptual DFT module. This theory analytically quantifies responses of the interatomic delocalization index (DI) to variations in the total electron number. See Section 3.25.6 of manual for introduction and Section 4.22.6 for example.
Hello,
It looks reasonable, please just try it.
I need more detailed information. At least all information outputed by sobEDA.sh should be provided, and error prompt part along with corresponding .gjf file of failed Gaussian task should be given.
I don't find any reason that "gen" is actually needed from you input file. I strongly suggest making things simple, namely using "pbe1pbe/def2SVP" keyword instead. Also scf=xqc should not be used when performing sobEDA, in the latest version of sobEDA tutorial you can find:
Note that scf=QC or scf=XQC should not be used, because output information of quadratic convergence code is incompatible with sobEDA.sh
When a relativistic Hamiltonian (like DKH in the present case), there is no analytical gradient but only numerical gradient in Gaussian, in this case you need to explicitly specify internal coordinate(s) to be optimized. For example, in the following case, only A1 will be optimized.
...
O
H 1 0.76533395
H 1 0.76533395 2 A1
A1=80.0Without analytical gradients, optimization task is quite time-consuming even for a medium-sized system at DFT level. So, without special reasons, I strongly do not recommend performing optimization with DKH in Gaussian. For geometry optimization purposes, commonly using a relativistic pseudopotential with a proper basis set is fully adequate.
STEOM-CCSD is not a blackbox method, in ORCA manual there are some discussions about fine-tune for the calculation, which affects convergence. If it doesn't work after various attempts, try to consider other methods with similar accuracy, such as the efficient LR-CC2 in e^T code (greatly accelerated by Cholesky decomposition).
"a single-point using STEOM-DLPNO-CCSD method" means calculating excited state energy (namely sum of excitation energy and ground state energy) at the given structure.
Best regards,
Tian Lu
Hello,
Perhaps due to network issue, currently I cannot view your uploaded pictures, I just reply you according to your text description:
1 If a paper only reports one pair of NTO, usually it means that there is only one NTO transition dominates the electronic excitation, for example, with contribution higher than 90-95%.
2 The hole-electron analysis in Multiwfn is not "looking at each pair", but generates hole and electron distributions, the hole->electron transition representation can always 100% describe any single-electron excitation, so it is particularly important and useful when there is no dominate MO transition or NTO transition.
You can use Multiwfn to generate cube file of hole and cube file of electron, respectively. Then they can be simultaneously shown in VMD (I am sure if it is also possible in VESTA), you just need to load the two cube files into VMD in turn, and then set both their drawing method as "Isosurface" and properly adjust isovalue in the Graphics - Representation interface.
Best regards,
Tian
1 You just need to use scrf=SMD, no additional keywords are needed.
2 For Br and I, I recommend to modify radii as mentioned in my blog article http://sobereva.com/613. For other elements, simply use the default radii in SMD should be OK.
For charged ions, uESE performs notably better than SMD, see http://sobereva.com/593. If you need better solvation energy of ions, using uESE instead is recommended.
3 I didn't take care of this parameter and thus cannot comment on it.
Hello,
Currently output file of ORCA+NBO is not officially supported by the AdNDP function in Multiwfn.
Dear K. Gayathri,
I cannot immdiately access your files because the webpage shows "You need access..." interface, perhaps verification step is needed. You can also send the files as attachment to my E-mail.
Usually DFT single-point calculations (except for double-hybrid functionals) in Gaussian 16, even for 213 atoms, do not need very large memory, as long as the basis set is not extremely large.
My suggestions:
(1) Simply set proper %nproc and %mem in template.gjf, which should be enough for the entire system, and you do not need to manually modify the template for different fragments
(2) I suggest first trying 6-31G* or def2-SVP and check if the energy decomposition can smoothly finish. If yes, then further enlarge the basis set.
(3) Sometimes the default memeory limit for formchk is not enough, which may cause segmentation violation. please run
export GAUSS_MEMDEF=20GB before execute the sobEDA script.
(4) If segmentation violation was caused by the steps of invoking Multiwfn, please make sure that you have carefully configurated the running environment for Multiwfn as described in Section 2.1.2 of Multiwfn manual.
(5) Please carefully check Section "1 Prerequisite" in the sobEDA tutorial document, so that all requirements are fully satisfied.
Best,
Tian
For convenience, now the permanent address for accessing Multiwfn is available:
Latest Linux source code
http://sobereva.com/multiwfn/misc/Multi … _Linux.zip
Latest Linux noGUI binary package
http://sobereva.com/multiwfn/misc/Multi … _noGUI.zip
Latest Windows binary package
http://sobereva.com/multiwfn/misc/Multi … n_Win64.7z
The addresses will not be changed, but the files will be automatically updated when new version of Multiwfn is released.
Sorry for the repeated request, but there is still a remaining issue with the input generated by multiwfn:
*******************************************************************************
* ___ *
* / \ *
* [ABORT] The specified keyword 'TYPE' is not available anymore: The keyword *
* \___/ MOTION/CELL_OPT/TYPE has been removed because cell optimizations *
* | now always use DIRECT_CELL_OPT. *
* O/| *
* /| | *
* / \ input/input_parsing.F:262 *
*******************************************************************************
This issue has been solved in Multiwfn 2026.8.21
Multiwfn 2026.8.19 has solved this issue.
Hello, I already noticed this issue recently, I will update the CP2K interface in the next release of Multiwfn.
Hello,
Unfortunately NTO is not supported for spin-flip case.
Multiwfn exports .47 file with E15.7 format and lower-triangular form for symmetric matrix. If you need to change the default behavior, please manually modify the source code. In fileIO.f90 you can find
call mat2arr(Sbas,halfmat,2)
write(ifileid,"(5E15.7)") halfmat(:)You can modify the outputting format, and changing mat2arr(Sbas,halfmat,2) to mat2arr(Sbas,halfmat,3) will export overlap matrix (Sbas) in upper-triangular form.
Please make sure that you are using the latest version of ORCA and Multiwfn. Old versions may have incompatible problem (ORCA frequently changes output format among different versions). If you are indeed using the latest versions, please send your ORCA output file to my E-mail, I will check.
It is fully possible, the only requirement is that you should load wavefunction file corresponding to excited state into Multiwfn, please check http://sobereva.com/wfnbbs/viewtopic.php?id=306
Hello,
I am not sure what you mean by G09 being unable to compute RESP charges. Both the ORCA and Gaussian09 manuals provide the necessary input to compute them.
For Gaussian09, the input is as follows:
```
#P HF/6-31G* Pop=MK IOp(6/33=2) IOp(6/41=15) IOp(6/42=15) IOp(6/50=1)
# Test Units(Ang,Deg)
```I am also using the MK method with Multiwfn, yet there is still a large discrepancy compared to ORCA, which uses COSMO I believe
Please carefully look at Kollman's original paper of RESP charge (J. Phys. Chem., 97, 10269 (1993)), and relevant part of Multiwfn manual (Section 3.9.16). RESP charge is not a variant of ESP fitting charge just with additional constraints, but it defined specific fitting scheme. The so-called RESP charge in ORCA and Gaussian only enable users to manually set simple constraints, while it doesn't directly follow the full procedure of RESP charge fitting in Kollman's paper, so the results are not comparable.
Even for MK charges, which is one of the simplest ESP fitting charge, the results of Multiwfn and ORCA/Gaussian can also be detectably different even based one exactly the same wavefunction, because the spatial distribution of fitting points are not completely identical in these programs. ESP fitting charge is known to be sensitive to distribution and density of fitting points. In Multiwfn, the default density of fitting points is fine enough and can lead to basically converged result, and the point distribution strictly follows the original MK definition.