Edits to documentation based on Jason's comments

docs-source/usersguide/application.rst

@@ -298,7 +298,7 @@ A First Example
 ***************
 
 Let’s begin with our first example of an OpenMM script. It loads a PDB file
-called :file:`input.pdb` that defines a biomolecular system, parameterizes it using the AMBER99SB force field and TIP3P water
+called :file:`input.pdb` that defines a biomolecular system, parameterizes it using the Amber99SB force field and TIP3P water
 model, energy minimizes it, simulates it for 10,000 steps with a Langevin
 integrator, and saves a snapshot frame to a PDB file called :file:`output.pdb` every 1000 time
 steps.
@@ -345,8 +345,8 @@ Then type
 
     python simulatePdb.py
 
-You can name your own scripts whatever you want, but their names should end with
-``.py``. Let’s go through the script line by line and see how it works.
+You can name your own scripts whatever you want.  Let’s go through the script line
+by line and see how it works.
 ::
 
     from simtk.openmm.app import *
@@ -380,7 +380,7 @@ defined by XML files.  OpenMM includes XML files defining lots of standard force
 If you find you need to extend the repertoire of force fields available,
 you can find more information on how to create these XML files in Section :ref:`creating-force-fields`.
 In this case we load two of those files: :file:`amber99sb.xml`, which contains the
-AMBER99SB force field, and :file:`tip3p.xml`, which contains the TIP3P water model.  The
+Amber99SB force field, and :file:`tip3p.xml`, which contains the TIP3P water model.  The
 :class:`ForceField` object is assigned to a variable called :code:`forcefield`\ .
 ::
 
@@ -420,7 +420,7 @@ the step size (0.002 ps).
 
 This line combines the molecular topology, system, and integrator to begin a new
 simulation.  It creates a :class:`Simulation` object and assigns it to a variable called
-\ :code:`simulation`\ .  A :class:`Simulation` object coordinates all the processes
+\ :code:`simulation`\ .  A :class:`Simulation` object manages all the processes
 involved in running a simulation, such as advancing time and writing output.
 ::
 
@@ -520,7 +520,7 @@ the single quotes around the file names.
 .. note::
 
     The :class:`AmberPrmtopFile` reader provided by OpenMM only supports "new-style"
-    :file:`prmtop` files introduced in AMBER 6. The AMBER distribution still contains a number of
+    :file:`prmtop` files introduced in AMBER 7. The AMBER distribution still contains a number of
     example files that are in the "old-style" :file:`prmtop` format. These "old-style" files will
     not run in OpenMM.
 
@@ -608,12 +608,14 @@ we would need to include it.
 Using CHARMM Files
 ******************
 
-Yet another option is to load files created by the CHARMM setup tools.  Those include a
-:file:`psf` file containing topology information, and an ordinary PDB file for the
-atomic coordinates.  In addition, you must provide a set of files containing the force
+Yet another option is to load files created by the CHARMM setup tools, or other compatible
+tools such as VMD.  Those include a :file:`psf` file containing topology information, and an
+ordinary PDB file for the atomic coordinates.  (Coordinates can also be loaded from CHARMM
+coordinate or restart files using the CharmmCrdFile and CharmmRstFile classes).  In addition,
+you must provide a set of files containing the force
 field definition to use.  This can involve several different files with varying formats and
-filename extensions such as :file:`prm`, :file:`rtf`, and :file:`str`.  To do this, load
-all the definition files into a :class:`CharmmParameterSet`
+filename extensions such as :file:`par`, :file:`prm`, :file:`top`, :file:`rtf`, :file:`inp`,
+and :file:`str`.  To do this, load all the definition files into a :class:`CharmmParameterSet`
 object, then include that object as the first parameter when you call :meth:`createSystem`
 on the :class:`CharmmPsfFile`.
 
@@ -643,6 +645,8 @@ on the :class:`CharmmPsfFile`.
 
         :autonumber:`Example,CHARMM example`
 
+Note that both the CHARMM and XPLOR versions of the :file:`psf` file format are supported.
+
 .. _the-script-builder-application:
 
 The Script Builder Application
@@ -650,8 +654,9 @@ The Script Builder Application
 
 One option for writing your own scripts is to start with one of the examples
 given above (the one in Section :ref:`a-first-example` if you are starting from a PDB file, section
-:ref:`using_amber_files` if you are starting from AMBER :file:`prmtop` and :file:`inpcrd` files, or section
-:ref:`using_gromacs_files` if you are starting from Gromacs gro and top files), then customize it
+:ref:`using_amber_files` if you are starting from AMBER :file:`prmtop` and :file:`inpcrd` files, section
+:ref:`using_gromacs_files` if you are starting from Gromacs :file:`gro` and :file:`top` files, or section
+:ref:`using-charmm-files` if you are starting from CHARMM files), then customize it
 to suit your needs.  Another option is to use the `OpenMM Script Builder`_ application.
 
 
@@ -726,12 +731,12 @@ For the main force field, OpenMM provides the following options:
 =============================  ================================================================================
 File                           Force Field                                                                     
 =============================  ================================================================================
-:code:`amber96.xml`            AMBER96\ :cite:`Kollman1997`
-:code:`amber99sb.xml`          AMBER99\ :cite:`Wang2000` with modified backbone torsions\ :cite:`Hornak2006`
-:code:`amber99sbildn.xml`      AMBER99SB plus improved side chain torsions\ :cite:`Lindorff-Larsen2010`
-:code:`amber99sbnmr.xml`       AMBER99SB with modifications to fit NMR data\ :cite:`Li2010`
-:code:`amber03.xml`            AMBER03\ :cite:`Duan2003`
-:code:`amber10.xml`            AMBER10 (documented in the AmberTools_ manual as `ff10`)
+:code:`amber96.xml`            Amber96\ :cite:`Kollman1997`
+:code:`amber99sb.xml`          Amber99\ :cite:`Wang2000` with modified backbone torsions\ :cite:`Hornak2006`
+:code:`amber99sbildn.xml`      Amber99SB plus improved side chain torsions\ :cite:`Lindorff-Larsen2010`
+:code:`amber99sbnmr.xml`       Amber99SB with modifications to fit NMR data\ :cite:`Li2010`
+:code:`amber03.xml`            Amber03\ :cite:`Duan2003`
+:code:`amber10.xml`            Amber10 (documented in the AmberTools_ manual as `ff10`)
 :code:`amoeba2009.xml`         AMOEBA 2009\ :cite:`Ren2002`.  This force field is deprecated.  It is 
                                recommended to use AMOEBA 2013 instead.
 :code:`amoeba2013.xml`         AMOEBA 2013\ :cite:`Shi2013`
@@ -772,16 +777,16 @@ the following files:
 =========================  =================================================================================================
 File                       Implicit Solvation Model                                                                      
 =========================  =================================================================================================
-:code:`amber96_obc.xml`    GBSA-OBC solvation model\ :cite:`Onufriev2004` for use with AMBER96 force field
-:code:`amber99_obc.xml`    GBSA-OBC solvation model for use with AMBER99 force fields
-:code:`amber03_obc.xml`    GBSA-OBC solvation model for use with AMBER03 force field
-:code:`amber10_obc.xml`    GBSA-OBC solvation model for use with AMBER10 force field
+:code:`amber96_obc.xml`    GBSA-OBC solvation model\ :cite:`Onufriev2004` for use with Amber96 force field
+:code:`amber99_obc.xml`    GBSA-OBC solvation model for use with Amber99 force fields
+:code:`amber03_obc.xml`    GBSA-OBC solvation model for use with Amber03 force field
+:code:`amber10_obc.xml`    GBSA-OBC solvation model for use with Amber10 force field
 :code:`amoeba2009_gk.xml`  Generalized Kirkwood solvation model\ :cite:`Schnieders2007` for use with AMOEBA 2009 force field
 :code:`amoeba2013_gk.xml`  Generalized Kirkwood solvation model for use with AMOEBA 2013 force field
 =========================  =================================================================================================
 
 
-For example, to use the GBSA-OBC solvation model with the AMBER99SB force field,
+For example, to use the GBSA-OBC solvation model with the Amber99SB force field,
 you would type:
 ::
 
@@ -812,7 +817,7 @@ with the :code:`implicitSolvent` parameter:
 
     system = prmtop.createSystem(implicitSolvent=OBC2)
 
-OpenMM supports most of the implicit solvent models used by AMBER.  Here are the
+OpenMM supports all of the Generalized Born models used by AMBER.  Here are the
 allowed values for :code:`implicitSolvent`\ :
 
 .. tabularcolumns:: |l|L|
@@ -834,7 +839,7 @@ You can further control the solvation model in a few ways.  First, you can
 specify the dielectric constants to use for the solute and solvent:
 ::
 
-    system = prmtop.createSystem(implicitSolvent=OBC2, soluteDielectric=2.0,
+    system = prmtop.createSystem(implicitSolvent=OBC2, soluteDielectric=1.0,
             solventDielectric=80.0)
 
 If they are not specified, the solute and solvent dielectrics default to 1.0 and
@@ -1453,7 +1458,7 @@ Once you have finished editing your model, you can immediately use the resulting
 :class:`Topology` object and atom positions as the input to a :class:`Simulation`.  If you plan to
 simulate it many times, though, it is usually better to save the result to a new
 PDB file, then use that as the input for the simulations.  This avoids the cost
-of repeating the modeling operations at the start of every simulation, and also
+of repeating the modelling operations at the start of every simulation, and also
 ensures that all your simulations are really starting from exactly the same
 structure.
 
@@ -1632,7 +1637,7 @@ Here is the definition of the :class:`ForceReporter` class:
             def report(self, simulation, state):
                 forces = state.getForces().value_in_unit(kilojoules/mole/nanometer)
                 for f in forces:
-                    print >>self._out, f[0], f[1], f[2]
+                    self._out.write('%g %g %g\n' % (f[0], f[1], f[2]))
 
     .. caption::
 

docs-source/usersguide/index.rst

@@ -7,8 +7,9 @@ OpenMM Users Manual and Theory Guide
 
 Portions copyright (c) 2008-2014 Stanford University and the Authors
 
-Contributors:  Kyle Beauchamp, Christopher Bruns, Peter Eastman, Mark
-Friedrichs, Joy P. Ku, Vijay Pande, Randy Radmer, Michael Sherman, Tom Markland
+Contributors:  Kyle Beauchamp, Christopher Bruns, John Chodera, Peter Eastman, Mark
+Friedrichs, Joy P. Ku, Tom Markland, Vijay Pande, Randy Radmer, Michael Sherman,
+Jason Swails, Lee-Ping Wang
 
 Permission is hereby granted, free of charge, to any person obtaining a copy of
 this document (the "Document"), to deal in the Document without restriction,

docs-source/usersguide/library.rst

@@ -1803,17 +1803,17 @@ The OpenCL Platform recognizes the following Platform-specific properties:
   “single”, nearly all calculations are done in single precision.  This is the
   fastest option but also the least accurate.  If it is set to “mixed”, forces are
   computed in single precision but integration is done in double precision.  This
-  gives much better energy conservation with only a slightly decrease in speed.
+  gives much better energy conservation with only a slight decrease in speed.
   If it is set to “double”, all calculations are done in double precision.  This
   is the most accurate option, but is usually much slower than the others.
-* OpenCLUseCpuPme: This selects whether to use the CPU based PME
+* OpenCLUseCpuPme: This selects whether to use the CPU-based PME
   implementation.  The allowed values are “true” or “false”.  Depending on your
   hardware, this might (or might not) improve performance.  To use this option,
   you must have FFTW (single precision, multithreaded) installed, and your CPU
   must support SSE 4.1.
 * OpenCLPlatformIndex: When multiple OpenCL implementations are installed on
-  your computer, this is used to select which one to use.  The value is the zero-
-  based index of the platform (in the OpenCL sense, not the OpenMM sense) to use,
+  your computer, this is used to select which one to use.  The value is the
+  zero-based index of the platform (in the OpenCL sense, not the OpenMM sense) to use,
   in the order they are returned by the OpenCL platform API.  This is useful, for
   example, in selecting whether to use a GPU or CPU based OpenCL implementation.
 * OpenCLDeviceIndex: When multiple OpenCL devices are available on your
@@ -1842,10 +1842,10 @@ The CUDA Platform recognizes the following Platform-specific properties:
   “single”, nearly all calculations are done in single precision.  This is the
   fastest option but also the least accurate.  If it is set to “mixed”, forces are
   computed in single precision but integration is done in double precision.  This
-  gives much better energy conservation with only a slightly decrease in speed.
+  gives much better energy conservation with only a slight decrease in speed.
   If it is set to “double”, all calculations are done in double precision.  This
   is the most accurate option, but is usually much slower than the others.
-* CudaUseCpuPme: This selects whether to use the CPU based PME implementation.
+* CudaUseCpuPme: This selects whether to use the CPU-based PME implementation.
   The allowed values are “true” or “false”.  Depending on your hardware, this
   might (or might not) improve performance.  To use this option, you must have
   FFTW (single precision, multithreaded) installed, and your CPU must support SSE
@@ -1873,7 +1873,7 @@ The CUDA Platform recognizes the following Platform-specific properties:
   synchronizes between the CPU and GPU.  If this is set to “true” (the default),
   CUDA will allow the calling thread to sleep while the GPU is performing a
   computation, allowing the CPU to do other work.  If it is set to “false”, CUDA
-  will spin-lock while the GPU is working.  This can improve performance slightly,
+  will spin-lock while the GPU is working.  Setting it to "false" can improve performance slightly,
   but also prevents the CPU from doing anything else while the GPU is working.
 
 
@@ -1978,7 +1978,7 @@ cases in which the C++ behavior cannot be directly mapped into C. These
 interface and helper functions are compiled in to the main OpenMM library so
 there is nothing special you have to do to get access to them.
 
-In the /\ :code:`include` subdirectory of your OpenMM installation directory,
+In the :code:`include` subdirectory of your OpenMM installation directory,
 there is a machine-generated header file :code:`OpenMMCWrapper.h` that
 should be #included in any C program that is to make calls to OpenMM functions.
 That header contains declarations for all the OpenMM C interface functions and
@@ -2008,7 +2008,7 @@ constructor                 new OpenMM::ClassName()                    | OpenMM_
 destructor                  | OpenMM::ClassName* thing;                | OpenMM_ClassName* thing;
                             | delete thing;                            | OpenMM_ClassName_destroy(thing);
 class method                | OpenMM::ClassName* thing;                | OpenMM_ClassName* thing;
-                            | thing->someName(args);                   | OpenMM_ClassName_someName(thing, args)
+                            | thing->method(args);                     | OpenMM_ClassName_method(thing, args)
 Boolean (type & constants)  | bool                                     | OpenMM_Boolean
                             | true, false                              | OpenMM_True(1), OpenMM_False(0)
 string                      std::string                                char*
@@ -2085,12 +2085,12 @@ conceptually since it differs slightly for each kind of object.
 =======================================================  =========================================================================================================================================================================================================
 Function                                                 Operation
 =======================================================  =========================================================================================================================================================================================================
-*Thing*\ Array\* create(int size)                        Create a heap-allocated array of *Things*\ , with space pre-allocated to hold :code:`size` of them. You can start at :code:`size`\ ==0 if you want since these arrays are dynamically resizeable.
+*Thing*\ Array\* create(int size)                        Create a heap-allocated array of *Things*\ , with space pre-allocated to hold :code:`size` of them. You can start at :code:`size==0` if you want since these arrays are dynamically resizeable.
 void destroy(\ *Thing*\ Array\*)                         Free the heap space that is currently in use for the passed-in array of *Things*\ .
-int getSize(\ *Thing*\ Array\*)                          Return the current number of *Things* in this array. This means you can :code:`get()` and :code:`set()` elements up to :code:`getSize()`\ -1.
+int getSize(\ *Thing*\ Array\*)                          Return the current number of *Things* in this array. This means you can :code:`get()` and :code:`set()` elements up to :code:`getSize()-1`\ .
 void resize(\ *Thing*\ Array\*, int size)                Change the size of this array to the indicated value which may be smaller or larger than the current size. Existing elements remain in their same locations as long as they still fit.
 void append(\ *Thing*\ Array\*, *Thing*\ )               Add a *Thing* to the end of the array, increasing the array size by one. The precise syntax depends on the actual type of *Thing*\ ; see below.
-void set(\ *Thing*\ Array\*, int index, *Thing*\ )       Store a copy of *Thing* in the indicated element of the array (indexed from 0). The array must be of length at least :code:`index`\ +1; you can’t grow the array with this function.
+void set(\ *Thing*\ Array\*, int index, *Thing*\ )       Store a copy of *Thing* in the indicated element of the array (indexed from 0). The array must be of length at least :code:`index+1`\ ; you can’t grow the array with this function.
 *Thing* get(\ *Thing*\ Array\*, int index)               Retrieve a particular element from the array (indexed from 0). (For some Things the value is returned in arguments rather than as the function return.)
 =======================================================  =========================================================================================================================================================================================================
 
@@ -2212,15 +2212,15 @@ special you have to do to get access to them.
 
 Because Fortran is case-insensitive, calls to Fortran subroutines (however
 capitalized) are mapped by the compiler into all-lowercase or all-uppercase
-names, and different compilers use different conventions. The automatically-
-generated OpenMM Fortran “wrapper” subroutines, which are generated in C and
+names, and different compilers use different conventions. The automatically-generated
+OpenMM Fortran “wrapper” subroutines, which are generated in C and
 thus case-sensitive, are provided in two forms for compatibility with the
 majority of Fortran compilers, including Intel Fortran and gfortran. The two
 forms are: (1) all-lowercase with a trailing underscore, and (2) all-uppercase
 without a trailing underscore. So regardless of the Fortran compiler you are
 using, it should find a suitable subroutine to call in the main OpenMM library.
 
-In the :code:`/include` subdirectory of your OpenMM installation directory,
+In the :code:`include` subdirectory of your OpenMM installation directory,
 there is a machine-generated module file :code:`OpenMMFortranModule.f90`
 that must be compiled along with any Fortran program that is to make calls to
 OpenMM functions. (You can look at the :code:`Makefile` or Visual Studio
@@ -2260,7 +2260,7 @@ constructor                 new OpenMM::ClassName()              | type (OpenMM_
 destructor                  | OpenMM::ClassName* thing;          | type (OpenMM_ClassName) thing
                             | delete thing;                      | call OpenMM_ClassName_destroy(thing)
 class method                | OpenMM::ClassName* thing;          | type (OpenMM_ClassName) thing
-                            | thing->someName(args*)             | call OpenMM_ClassName_someName(thing, args)
+                            | thing->method(args*)               | call OpenMM_ClassName_method(thing, args)
 Boolean (type & constants)  | bool                               | integer*4
                             | true                               | parameter (OpenMM_True=1)
                             | false                              | parameter (OpenMM_False=0)
@@ -2282,8 +2282,8 @@ OpenMM_Vec3 helper type
 =======================
 
 Unlike the other OpenMM objects which are opaque and manipulated via pointers,
-the Fortran API uses an ordinary :code:`real`\ :code:`*8(3)` array in
-place of the :code:`OpenMM::Vec3` type. The
+the Fortran API uses an ordinary :code:`real*8(3)` array in
+place of the :code:`OpenMM::Vec3` type.
 You can work directly with the individual elements of this type from your
 Fortran program if you want. For convenience, a :code:`scale()` function is
 provided that creates a new Vec3 from an old one and a scale factor:
@@ -2561,7 +2561,9 @@ notable differences:
 
     myContext.getState(getEnergy=True, getForce=False, …)
     
-#. Wherever the C++ API uses references to return multiple values from a method, the Python API returns a tuple.  For example, in C++ you would query a HarmonicBondForce for a bond’s parameters as follows:
+#. Wherever the C++ API uses references to return multiple values from a method,
+   the Python API returns a tuple.  For example, in C++ you would query a
+   HarmonicBondForce for a bond’s parameters as follows:
    ::
 
     int particle1, particle2;
@@ -2574,8 +2576,8 @@ notable differences:
     [particle1, particle2, length, k] = f.getBondParameters(i)
 
 #. Unlike C++, the Python API accepts and returns quantities with units attached
-   to most values (see the “Units and dimensional analysis” section below for
-   details).  In short, this means that while values in C++ have *implicit*\
+   to most values (see Section :ref:`units-and-dimensional-analysis` below for
+   details).  In short, this means that while values in C++ have *implicit*
    units, the Python API returns objects that have values and *explicit* units.
 
 
@@ -2709,6 +2711,9 @@ multiply operator (‘*’) or the explicit Quantity constructor:
     # or more verbosely
     bond_length = Quantity(value=1.53, unit=nanometer)
 
+When working with Numpy arrays you *must* use the explicit constructor.  You cannot
+multiply them by a unit, because the Numpy array class overloads the multiply operator.
+
 
 Arithmetic with units
 ---------------------
@@ -2847,22 +2852,22 @@ in and out.
 ::
 
     >>> a = Vec3(1,2,3) * nanometers
-    >>> print a
+    >>> print(a)
     (1, 2, 3) nm
-    >>> print a.in_units_of(angstroms)
+    >>> print(a.in_units_of(angstroms))
     (10.0, 20.0, 30.0) A
 
     >>> s2 = [[1,2,3],[4,5,6]] * centimeter
-    >>> print s2
+    >>> print(s2)
     [[1, 2, 3], [4, 5, 6]] cm
-    >>> print s2 / millimeter
+    >>> print(s2/millimeter)
     [[10.0, 20.0, 30.0], [40.0, 50.0, 60.0]]
 
     >>> import numpy
     >>> a = Quantity(numpy.array([1,2,3]), centimeter)
-    >>> print a
+    >>> print(a)
     [1 2 3] cm
-    >>> print a / millimeter
+    >>> print(a/millimeter)
     [ 10.  20.  30.]
 
 Converting a whole list to different units at once is much faster than
@@ -2872,13 +2877,13 @@ Angstroms:
 ::
 
     for v in state.getPositions():
-        print v.value_in_unit(angstrom)
+        print(v.value_in_unit(angstrom))
 
 This can be rewritten as follows:
 ::
 
     for v in state.getPositions().value_in_unit(angstrom):
-        print v
+        print(v)
 
 The two versions produce identical results, but the second one will run faster,
 and therefore is preferred.
@@ -2896,8 +2901,8 @@ GROMACS is a large, complex application written primarily in C.  The
 considerations involved in adapting it to use OpenMM are likely to be similar to
 those faced by developers of other existing applications.
 
-The first principle we followed in adapting GROMACS was to keep all OpenMM-
-related code isolated to just a few files, while modifying as little of the
+The first principle we followed in adapting GROMACS was to keep all OpenMM-related
+code isolated to just a few files, while modifying as little of the
 existing GROMACS code as possible.  This minimized the risk of breaking existing
 parts of the code, while making the OpenMM-related parts as easy to work with as
 possible.  It also minimized the need for C code to invoke the C++ API.  (This
@@ -3566,9 +3571,9 @@ the ring polymer representing each particle is directly related to its De
 Broglie thermal wavelength (uncertainty in its position).
 
 RPMD calculations must be converged with respect to the number *n* of beads
-used.  Each bead is evolved at the effective temperature *nT*\ , where *T*\
+used.  Each bead is evolved at the effective temperature *nT*\ , where *T*
 is the temperature for which properties are required.  The number of beads
-needed to converge a calculation can be estimated using\ :cite:`Markland2008`\
+needed to converge a calculation can be estimated using\ :cite:`Markland2008`
 
 
 .. math::

docs-source/usersguide/theory.rst

@@ -20,7 +20,7 @@ On the other hand, many details are intentionally left unspecified.  Any
 behavior that is not specified either in this guide or in the API documentation
 is left up to the Platform, and may be implemented in different ways by
 different Platforms.  For example, an Integrator is required to produce a
-trajectory that satisfies constraints to within the user specified tolerance,
+trajectory that satisfies constraints to within the user-specified tolerance,
 but the algorithm used to enforce those constraints is left up to the Platform.
 Similarly, this guide provides the functional form of each Force, but does not
 specify what level of numerical precision it must be calculated to.
@@ -164,7 +164,7 @@ Each torsion pair is represented by an energy term of the form
 
 
 where :math:`\theta_1` and :math:`\theta_2` are the two dihedral angles
-coupled by the term, and *f*\ (\ *x*\ ,\ *y*\ ) is defined by a user supplied
+coupled by the term, and *f*\ (\ *x*\ ,\ *y*\ ) is defined by a user-supplied
 grid of tabulated values.  A natural cubic spline surface is fit through the
 tabulated values, then evaluated to determine the energy for arbitrary (\ :math:`\theta_1`\ ,
 :math:`\theta_2`\ ) pairs.
@@ -1136,7 +1136,7 @@ VariableVerletIntegrator
 
 This is very similar to VerletIntegrator, but instead of using the same step
 size for every time step, it continuously adjusts the step size to keep the
-integration error below a user specified tolerance.  It compares the positions
+integration error below a user-specified tolerance.  It compares the positions
 generated by Verlet integration with those that would be generated by an
 explicit Euler integrator, and takes the difference between them as an estimate
 of the integration error:
@@ -1161,7 +1161,7 @@ specified error tolerance:
 
 
 where :math:`\delta` is the error tolerance.  This is the largest step that may be
-taken consistent with the user specified accuracy requirement.
+taken consistent with the user-specified accuracy requirement.
 
 (Note that the integrator may sometimes choose to use a smaller value for :math:`\Delta t`
 than given above.  For example, it might restrict how much the step size