"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 7.0, available in Windows 10 and linux/unix/Mac environments. Binary NBO 7.0 offers lower price, easier installation, and full-featured interactivity with all NBO7-compatible ESS binary programs, but can also function as a stand-alone GenNBO program to analyze wavefunctions produced by older ESS binaries. Binary NBO 7.0 is therefore ready to "load and go" with your favorite ESS host program.

For program developers or those wishing to build ESS/NBO7 or GenNBO7 applications in uncommon OS or hardware environments, the source version of NBO 7.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 NBO7 program occurs through the $NBO keylist that is inserted into the host ESS input file (for interactive ESS/NBO7 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, $WF...) are also described in the manual.


NBO7 builds on the "link-free" message-passing paradigm for ESS/NBO interactivity that was introduced in NBO6. In this mode, unlinked ESS and NBO7 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. These deep structural differences from pre-NBO6 versions — whether in interactive ESS/NBO or stand-alone GenNBO applications — will be transparent to the experienced NBO user, for whom $NBO keyword and keylist input works as in previous NBO versions.

News Archive FAQ Featured apps NBO team contact us

Check most recent bug fixes here

(See also discussions on the NBO Forum)

Q1. Does NBO 7.0 work with older Gaussian or GAMESS versions? Do pre-NBO6 or other older NBO versions work with current Gaussian or GAMESS versions?
NBO 7.0 works interactively with all recent versions of ESS host programs (GAMESS, Gaussian, Molpro, Orca, Terachem) that supported NBO6-level interactivity (e.g., G09 Rev. D or later). Older NBO versions that required linking to a host ESS program can no longer work interactively with any current ESS version. NBO 7.0 can also run non-interactively (in stand-alone GenNBO mode) to analyze output from many other NBO-affiliated programs that produce valid NBO archive (.47) file output.

Q2. For some reason the NRT (or STERIC, or CMO, or NBCP,...) keyword isn't accepted, even though I have the latest version of Gaussian. What's wrong?
Gaussian program packages are still 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 7.0 program to access the full range of modern NBO-based analysis options (but see Q3).

Q3. How can I use NBO 7.0 with G16W or other binary Windows 10 programs?
Newer NBO7-compatible G16W binaries will work immediately with NBO 7.0 binaries in full-featured interactive manner. However, early G09W and prior Gaussian binary versions can only work with NBO 7.0 in stand-alone GenNBO mode, by using the older NBO3-level ARCHIVE (.47) files that are still readable by current NBO programs. (Transient problems with .47 files from G09 Rev. C.01 were subsequently 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, and in all cases the NPA atomic charges should be invariant to changes in coordinate system.

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?
This problem only occurs with pre-NBO7 versions of the NRT algorithm. In earlier NBO versions, the hang usually results from a case where "apparent hypervalency" was detected and the program attempted to restart 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.) For pre-NBO7 users, the only 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 which case the inadequate memory will lead to an early abort, rather than an infinite hang. The preferred solution is to upgrade to NBO7.

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 NBOPro@Jmol 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. NBOPro@Jmol 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. 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 7.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 7.0 in this respect, please see the update.

Q15. 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 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 Gaussian distributions.)

Q16. My DFT deletions (POP=DEL) jobs with G09 no longer agree with results from earlier or later Gaussian versions. What's wrong?
An integration option was modified in G09 that affected 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 affected revisions A, B, C of G09, but was remedied in subsequent revisions.

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 NBOPro@Jmol, feel free (in good conscience) to click(-and-hold) the orbital selector a second time to reverse initial orbital sign and restore the expected in-phase superposition of donor and acceptor orbitals.
I'd like to upgrade my binary NBO7 license to a source NBO7 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 NBO7.

Q19. 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 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.

Q21. Can NBO 7.0 be altered to deal with larger systems or basis sets?

Yes and no. If you have source NBO 7.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 7.0, no such source code changes are possible.

Q22. 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.

Q23. 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.

Q24. 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.

Q25. 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.

Q26. 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.

Q27. 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.

Q28. I just installed NBOPro7@Jmol, more or less according to instructions, but any attempt to "Select Job" on the RUN menu (following the illustrative example of the HELP button) leads to "NBOPro can't do that" error condition. What's wrong?

You probably need to reinstall with closer attention to suggested folder-names. In particular, choose a top-level folder for binary or work files (e.g., "C:\nbopro7_work"), not a deeply buried sub-folder in the heirarchical structure of the default Windows 10 file system. Excessively long file-specification strings foul communication among the various programs that cooperate to service NBOPro7@Jmol commands.

[Serbo-Croatian translation: Anja Skrba]
[Romanian translation: Irina Vasilescu
[Russian translation: Sandi Wolfe]
[Mandarin translation: Refermate.com]

NBO Home