"In so far as quantum mechanics is correct, chemical questions are problems in applied mathematics." - Henry Eyring

Source or Binary?

Most users will prefer binary versions of NBO 6.0, available in all popular Windows and linux/unix/Mac environments. Binary NBO 6.0 offers lower price, easier installation, and full-featured interactivity with all NBO6-compatible ESS binary programs, but can also function as a stand-alone GenNBO program to analyze wavefunctions produced by older ESS binaries. Binary NBO 6.0 is therefore ready to "load and go" with your favorite ESS host program.

For program developers or those wishing to build ESS/NBO6 or GenNBO6 applications in uncommon OS or hardware environments, the source version of NBO 6.0 is also available. This requires compilation and linking of fortran and C code using OS-specific utilities on a chosen platform.

$NBO Keylist Input

Communication between the user and the NBO6 program occurs through the $NBO keylist that is inserted into the host ESS input file (for interactive ESS/NBO6 implementations) or the .47 input file (for stand-alone GenNBO implementation). This has generic form

$NBO (keywords) $END

where "(keywords)" are chosen NBO options described in the NBO Manual. Other specialized keylists ($DEL, $CHOOSE, $NRTSTR,...) are also described in the manual.


NBO6 offers a new paradigm for ESS/NBO interactivity -- unlinked message-passing. In this mode, unlinked ESS and NBO6 binary programs are launched simultaneously, whereupon they cooperatively communicate and interact as a binary pair to perform the tasks requested in the ESS input file. All this--whether in interactive ESS/NBO or stand-alone GenNBO applications--is transparent to the experienced NBO user, who prepares $NBO keylist input as in previous NBO versions.

News Archive FAQ Forum Featured apps NBO team contact us

Check most recent bug fixes here

(See also discussions on the NBO Forum)

Q1. Does NBO 6.0 work with older Gaussian or GAMESS versions? Do NBO 5.9 or other older NBO versions work with current Gaussian or GAMESS versions?
NBO 6.0 works interactively only with newer NBO6-compatible host ESS programs (such as G09 Ref. D.01 or later). [However, a special procedure allows linking the source version of NBO 6.0 with earlier (pre-Rev. D) source versions of Gaussian 09.] Older NBO versions (with their attendant compiling and linking procedures) cannot work with any recent Gaussian (Rev. D or later) or GAMESS version. [However, NBO 6.0 can also run non-interactively in stand-alone GenNBO mode, able to analyze output from many older host ESS programs that produce valid NBO archive (.47) files.]

Q2. For some reason the NBCP (or NRT, STERIC, CMO,...) keyword isn't accepted, even though I have the latest version of Gaussian. What's wrong?
Gaussian program packages are distributed with NBO 3.1, the antiquated (1980s-vintage) program that lacks all such options and is no longer supported by the NBO development team. You must upgrade to the current NBO 6.0 program to access the full range of modern NBO-based analysis options (but see Q3).

Q3. How can I use NBO 6.0 with G09W or other binary PC-Windows programs?
Newer NBO6-compatible G09W binaries will work immediately with NBO 6.0 binaries in full-featured interactive manner. However, earlier G09W versions can only work (non-interactively) with NBO 6.0 in stand-alone GenNBO mode, by using the older NBO3-level ARCHIVE (.47) files from G09W that are still readable by current NBO programs. (Transient problems with .47 files from G09 Rev. C.01 were resolved.)

The specific steps are as follows:

(1) Create the NBO archive file (xxx.47) from your G09W run. To do so, include the "archive" keyword and chosen filename "file=myjob" in the $NBO keylist of your Gaussian input file (with the usual POP=NBOREAD on the route card), then look for the "myjob.47" file produced by this run.
(2) Modify the myjob.47 file by adding the desired keyword options to the $NBO...$END keylist in the second line of this file. Then give the command "gennbo myjob" and look for the "myjob.nbo" output file that results.

Q4. With Gaussian I tried to evaluate NPA charges at a correlated MP2 level, but the results seemed to be identical to uncorrelated HF results. What's wrong?
You must include "DENSITY=CURRENT" (or "DENSITY=MP2") in the Gaussian route card to analyze higher-level corrections to the HF density.

Q5. My Gaussian job didn't produce any NBO output but instead gave the message, "NBO is unable to handle linearly dependant basis sets." What does this mean, and what can I do?
The Gaussian program checks for numerical instabilities due to near-linear dependence of basis functions (chiefly due to inclusion of diffuse functions) and reduces the dimension of the basis set if necessary. When this occurs, some Gaussian versions print the above error message and bypass entry to NBO. A solution is to include IOP(3/32=2) to bypass the Gaussian linear dependence test, relying on the more reliable linear dependence remedies within the NBO program itself. However, if linear dependence is truly severe, the only alternative may be to remove "+" or other basis functions until the Gaussian linear dependency fix is not triggered.

Q6. When I perform $DEL deletions with Gaussian, the program says that the SCF is "not converged." Does this indicate an error?
No. The $DEL procedure uses the converged Fock (or Kohn-Sham) operator for single-pass energy evaluation of a deleted density that differs from the "converged" (full) density. Hence, this message can be safely ignored.

Q7. I compared NPA from a job run on Jaguar and Gaussian and found that many NAO populations differ in the two programs. Who's right?
Both are. If internal input coordinates are employed, different program systems often use a different choice of cartesian coordinate system. Under these conditions, the meaning, e.g., of "x" is different (relative to molecular orientation) in the two calculations, and the populations of "p(x)" NAO will differ accordingly. Nevertheless, the two programs should give all the same NAO populations if the coordinate axes are chosen consistently.

Q8. My MP2 calculation under Gaussian led to many warning messages about "non-physical" occupancies and eventually stopped. What's wrong?
MP2 and related perturbative methods lead to an approximate density that is not physically consistent with an N-particle wavefunction (i.e., not N-representable) order by order. These perturbative inconsistencies are insignificant when the perturbative series is well behaved, but they sometimes become serious (forcing abandonment of NBO analysis) for spin-contaminated open-shell systems and other ill-converged cases. In such cases the NBO error messages warn that the MP2 density is unreliable. The FIXDM keyword can suppress some of these error messages, but cannot "correct" for a physically non-convergent perturbation expansion.

Q9. My NRT job goes into an infinite hang that requires killing the job. How can I recognize that the job is hung, and what can I do to prevent it?
The hang probably results from a case where apparent hypervalency was detected and the program attempted to restart NRT with the NRTFDM option using the full (rather than valence-only) density matrix, but without sufficient memory to accomodate necessary reference structures. (Look for the "apparent hypervalency" message near the bottom of the .LOG file to see if this type of hang is likely.) The solution is to provide additional memory for possible hypervalent cases, and/or to include the NRTFDM keyword so that the full density matrix is used from the outset. In this case, inadequate memory will lead to an early abort, rather than an infinite hang.

Q10. I tried to go to a higher-level MP2 or CASSCF treatment, but suddenly there were no NBO orbital energies and no table of 2nd-order perturbative energies? What's wrong?
NBO evaluates "orbital energies" and 2nd-order stabilization energies only when there is a well-defined 1-electron effective Hamiltonian operator (e.g., Fock or Kohn-Sham operator). Such an operator is unavailable for correlated descriptions, except those of DFT type.

Q11. I often see a warning message about "population inversion" after NPA analysis. Should I be worried?
Probably not. The "inversion" (occupancy ordering inconsistent with energy ordering) probably occurs for Rydberg-type orbitals of very low occupancy or near-degeneracy in occupancy or energy, so that no significant physical effects are indicated. The contrary case of an "inversion" involving high-occupancy, non-degenerate orbitals indicates an excited state.

Q12. How can I get orbital diagrams of NBOs or other natural localized orbitals?
If the ESS has integrated NBO and a read-write file, the checkpointing (or SPARTAN) options may allow you to use standard MO-plotting methods to plot the localized orbitals written (over the MOs) into this file. The NBOView utility program (see order info) provides a more general way to obtain 1-d amplitude profiles, 2-d contour plots, or rendered 3-d photograph-like images for any desired localized orbitals, using the input files created by the PLOT keyword. NBOView orbital imagery is illustrated in the homepage logo and elsewhere throughout this website.

Q13. I can't compile gennbo.f with the g77 compiler on my linux system. What's wrong?
Use the compiler directive

g77 -Wno-globals -fno-globals gennbo.f -o gennbo

to bypass checks for strict consistency between defined vs. called subroutine argument lists.

Q14. My nbo_59.src file contains many "^@" control characters that were not on the original CD. What happened?
The .src textfile may have been transferred between different operating systems using a Windows-type ftp utility with "T/B" (rather than text "T") as the default file-type setting.

Q15. I am working with lanthanides and/or actinides. Does the NPA partitioning scheme recognize the 5d (for lanthanides) and 6d (for actinides) subshell as a "valence" subshell, and will this affect my NPA charges?
All recent NBO versions (including NBO 6.0) recognize these subshells as valence orbitals, consistent with the observed partial occupancy of these subshells in certain ground-state atoms of the "f-block" lanthanides and actinides [J. Comput. Chem. 28: 198-203, 2007]. (The NPA partitioning for lanthanides/actinides is now consistent with long-established treatment of main and transition blocks and known ground-state atomic configurations. Older NBO versions conformed to the Madelung Rule, which forces some lanthanides and actinides to be analyzed in terms of excited-state atomic configurations.) This change can affect the NPA charges [J. Chem. Phys. 121, 2563-2570, 2004]. For the code-change to make older NBO versions consistent with current NBO 6.0 in this respect, please see the update.

Q16. The NBOView for MacOSX installation instructions failed to work on my Macintosh. What's wrong?
The libraries used by NBOView are not consistently available on newer Macintosh models. You can use Xcode 3.1.2 (downloaded from Apple Developers Web Site) and the gnu compiler gcc4.4 for Intel macs (downloaded from http://hpc.sourceforge.net/) to compile and link the NBOView program with the following commands (using the Terminal application):

(1) Compile the draw.c program with the gnu compiler using the following gcc command:

gcc -c -D_XWINDOWS -D_MACOSX draw.c

(2) Now compile the nboview.f fortran code and link it to the draw.o object file and X-windows library with the gnu compiler using the following gfortran command:

gfortran nboview.f draw.o -L/usr/X11R6/lib -lX11 -o nboview

(3) Finally, remove the draw.o object file:

rm draw.o

You should now have an executable nboview program that can be invoked by typing ./nboview from the Terminal application.

Q17. My NICS-type NMR calculation with the NCS keyword has chronically failed in recent G09/NBO5 versions. What's the latest on this issue?
All known NCS problems with the "MO" option have been resolved. However, NICS-type calculations with Bq atoms may still encounter an error ("Subroutine NAOANL could not find a s-type valence orbital on atom gh ...") depending on the compiler and processor used to build the G09 host program. For G09 (or G03) built with the Intel Fortran compiler on Itanium processors, NICS calculations are performed without error. However, compilation with PGF for Nehalem processors (as recommended in G09 instructions) leads to errors in NICS applications. (Check back for current info as further attempts are made to resolve this issue. Thanks to Dr. Miri Karni for recognizing compiler-specific idiosyncrasies of recent G03/G09 distributions.)

Q18. My attempt to compile GENNBO for Mac OSX platorm failed with g77. With gfortran, compilation apparently succeeded (no error message), but the resulting gennbo.exe program terminated abruptly. What's wrong?
For obscure reasons, 64-bit Mac OSX systems must be selected with the "32-bit integer" option for use with available open-source compilers. The resulting gennbo.f code can then be compiled with gfortran (not g77, which is apparently at the end of its development cycle), using, e.g.,

         gfortran gennbo.f -o gennbo_32

(Ignore the many warnings about HOLLERITH to INTEGER conversion.) This produces a gennbo_32.exe that should run successfully as a 32-bit application.

Q19. My DFT deletions (POP=DEL) jobs with G09 no longer agree with corresponding G03 jobs. What's wrong?
An integration option was modified in G09 that affects all $DEL evaluations with DFT methods. All G09 users should re-run such jobs with the IOp work-around illustrated below:

         #B3LYP/6-31+G* Pop=NBODel SCF=NoVarAcc IOp(5/48=100000)

The error affects current (12/15/2011) revision C and former revisions A, B of G09, but is to be remedied in forthcoming revisions.

Q20. My attempt to compile gennbo.f on Ubuntu 11.10 (32 bit x86) with gfortran gave an executable that did not work with ORCA. I then installed and tried the g77 compiler (as in Q13), but this failed with "cannot find" error messages for crtl.o, crti.o ("No such file or directory") and -lgcc_s. What's wrong?
The g77 compiler is not finding needed shared libraries. Two steps are needed to fix this:

Step 1 (in terminal):

         export LIBRARY_PATH

Step 2 (in terminal, in i486-linux-gnu directory):

The broken symlink to the missing libgcc_s.so library (/usr/lib/gcc/i486-linux-gnu/libgcc_s.so) can be repaired with the command:

         sudo ln -s /lib/i386-linux-gnu/libgcc_s.so.1 libgcc_s.so

Then the g77 compile command of Q13 should work correctly.
When I visualize the orbitals (or look up the PNBO overlap integral) for the expected E(2) donor-acceptor stabilization interaction, I find instead that the donor-acceptor overlap is negative (out-of-phase, "antibonding"). What's wrong?
Nothing. Donor-acceptor E(2) values (or indeed any quantum mechanical observables) can only depend on the absolute square of the wavefunction, not on the phase (sign) of individual orbitals. Indeed, the sign of any particular donor-acceptor overlap integral will depend on an arbitrary choice of coordinate system that has no physical significance. In the underlying perturbation theory leading to E(2) values, the perturbative mixing coefficients for donor or acceptor orbitals of "wrong" phase will automatically be taken with opposite sign to maintain proper in-phase "bonding" relationship. [You can verify this by looking at details of the resultant NLMO, in which donor and acceptor NBOs will be found to mix with opposite signs whenever the direct Fock matrix element (or associated PNBO overlap integral) of the E(2) numerator appears to be of "wrong" sign.] If viewing the orbitals with NBOView, feel free to use the SIGN command in good conscience to reverse any particuar orbital sign and restore the expected in-phase superposition of donor and acceptor orbitals.
I'd like to upgrade my binary NBO6 license to a source NBO6 license? Is that possible?
Yes. Contact the NBO Business Manager (tcinbo@chem.wisc.edu) with the download code from your earlier binary license to arrange purchase of a source license that will only be charged the difference between source and binary NBO6.

Q23. Is there any way to use NBO 5.9 in NBO6-compatible G09 Rev. D.01?
A one-line modification to the NBO 5.9 source code must be made so that it links appropriately to G09 D.01. Search the l607.F file for NBO 5.9 for the first (and only) occurrence of the statement (near line 43,856):


Insert the line

IOP(40) = IOP(40) - 1

immediately before this statement. Proceed to build G09. The resulting l607.exe executable should be a fully functioning NBO 5.9. This change to the NBO 5.9 source should not be made for pre-D.01 versions of G09.

Q24. Why does NBO analysis report what appear to be extra orbitals when using GAMESS with spherical basis functions?
If spherical functions are requested (ISPHER=1 in $CONTRL), GAMESS eliminates the Cartesian components (e.g. the s-component of a Cartesian d-type shell) from consideration in the SCF evaluation of the wavefunction. However, all information passed by GAMESS to NBO about this wavefunction (AO overlaps, Fock matrix, density matrix, etc.) is still expressed in the full Cartesian set, rather than truncated spherical set. NPA will report, for example, that a C atom has four s-type functions, when using spherical 6-31G*, although only three of these functions were actually considered in the SCF procedure.

In principle, the extra Cartesian components of the basis set should reveal exact zero occupancies. In practice, however, small occupancies (often of order 0.00001-0.00010e) are reported. These occupancies arise because the vectors of the Cartesian AO space that GAMESS eliminates are not exactly the extra Cartesian components of the basis set. These vectors have considerable Cartesian component character, but may also include fairly strong mixing with other basis functions.

Despite what's said in Q3, the archive .47 files produced by my recent G09W program can't be used by any current GenNBO program. What's wrong?

Programming changes were made in G09 that violate standard .47 formatting and make the NBO archive files from "NBO 3.1" unusable in both linux- and windows-based distributions. The problem persists in Rev. D.01, but is expected to be corrected in a future revision. Dr. Wojciech Kolodziejczyk has contributed a useful python app to correct this problem.

Q26. Can NBO 6.0 be altered to deal with larger systems or basis sets?

Yes and no. If you have source NBO 6.0 (see Q22), you can increase the maximum number of atoms (MAXATM) from default 500 up to 999, or the maximum number of basis functions (MAXBAS) from default 5000 up to 9999, by (carefully!) editing the corresponding PARAMETER declarations throughout the fortran code. If you have binary NBO 6.0, no such source code changes are possible.

Q27. How accurate is NBO? Are there known issues that prevent it from always accurately modelling a molecule?

NBO will search vigorously for the "best" single Lewis structure (NLS) description of the input wave function, but there is no assurance that such NLS description always achieves high accuracy. The percentage non-Lewis occupancy (%ρNL, printed just above the NBO listing) is the relevant numerical metric of NLS "error" for each species. Increased %ρNL errors are typically associated with increased resonance-type character of highly delocalized aromatic, transition state, or metallic species [see, e.g., Inorg. Chem. 52, 5166 (2013)], necessitating NRT-level analysis for more accurate description.

Q28. Is it possible to model two compounds that are not bonded to observe how they might interact most favorably (via donor-acceptor interactions)?

Yes. The "2nd-order perturbation theory analysis" that appears routinely in NBO output for HF/DFT wavefunctions gives direct "E(2)" numerical estimates of donor-acceptor interactions both within (intramolecular) and between (intermolecular) "molecular units". For higher correlated theory levels where a HF/DFT-type 1e effective Hamiltonian is unavailable, evidence for such interactions can also be seen in the fractional NRT bond orders between atoms in different molecules. Chapter 5 of Discovering Chemistry with Natural Bond Orbitals (Wiley, 2012) describes numerous additional options ($DEL, $CHOOSE, NLMO delocalization tails, graphical display of PNBO overlaps...) for studying such interactions and their dependence on intermolecular geometry.

Q29. The calculated NBO charges are far from the expected oxidation number that we normally calculate for a transition metal. Which is right? And how do we think about oxidation number if NBO is correct?

Oxidation number is a formal "bookkeeping" assignment of electronic charge that can only be physically realistic in the extreme ionic limit (as approached, e.g., in certain Zn2+ complexes). Numerous lines of computational and experimental X-ray, IR, NMR... evidence indicate that NPA and other similarly-nuanced (non-integer) electronic descriptors provide the more accurate picture of charge distribution in the vast majority of transition metal species, consistent with significant covalency of bonding interactions. Nevertheless, oxidation number retains usefulness as a labelling convention of chemical nomenclature.

Q30. I requested PLOT and ARCHIVE output (with "$NBO PLOT ARCHIVE $END" keylist), but no .31-.46 plot files or .47 archive file were produced. What's wrong?

You should include a proper FILE identifier (e.g., "$NBO FILE=myjob PLOT ARCHIVE $END) to insure that the requested files are created with names (i.e., "myjob.31",..., "myjob.47") that are recognizable after the job completes. Without such FILE identifier, the files may be generated with unpredicable (system-dependent) filestems or left in scratch storage that is overwritten, inaccessible, or difficult to recover.

Q31. The NBOPro6 program installed on our PC-Windows (Korean) OS displays text characters that are improperly sized with respect to surrounding frame and graphics display. What's wrong?

This problem is apparently systemic for PCs with installed Windows-CJK (Chinese/Japanese/Korean) operating system and character sets. The only known solution is to re-install Windows-EN (English) OS on such PCs. Further information about CJK characters can be found in the links below:
CJK characters
Halfwidth and fullwidth forms
Thanks to Daeho Hong for this information.

Q32. How can I decide whether an "individual" or "site" license is appropriate?

An individual license is for a single research group or personal individual. A site license is for any multi-group, departmental, campus, or institutional computer center. In each case, the registered license holder must have direct administrative or ownership control of any computer(s) on which the program is resident. Program output from each properly licensed NBO program includes identification of the individual or institutional site for which the license was purchased.

[Serbo-Croatian translation: Anja Skrba]
[Romanian translation: Irina Vasilescu
[Russian translation: Sandi Wolfe]

NBO Home