"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 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.
Message-Passing
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.
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:
The error affected
revisions A, B, C of G09,
but was remedied in subsequent revisions.
Q17.
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.
Q18.
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.
Q20.
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.
