"In so far as quantum mechanics is correct, chemical questions are
problems in applied mathematics."
- Henry Eyring
NBO USAGE OVERVIEW
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,
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
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
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)
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).
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.
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.
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.
When I perform $DEL deletions with Gaussian, the program says
that the SCF is "not converged." Does this indicate
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
I compared NPA from a job run on Jaguar and Gaussian and
found that many NAO populations differ in the two programs. Who's
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.
My MP2 calculation under Gaussian led to many warning messages
about "non-physical" occupancies and eventually stopped. What's
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.
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
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.
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.
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
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.
I can't compile gennbo.f with the g77 compiler on my linux system.
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.
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.
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.
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:
You should now have an executable nboview program that can be invoked
by typing ./nboview from the Terminal application.
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
My attempt to compile GENNBO for Mac OSX platorm failed with g77. With
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.
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:
The error affects current (12/15/2011) revision C and former
revisions A, B of G09,
but is to be remedied in forthcoming revisions.
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:
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
Yes. Contact the NBO Business Manager (email@example.com)
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.
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
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
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
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.
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.
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.
Is it possible to model two compounds that are not bonded to
observe how they might interact most favorably (via donor-acceptor
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.
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.
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.
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:
Halfwidth and fullwidth forms
Thanks to Daeho Hong for this information.