Apply suggestions from code review

Co-authored-by: Paul Romano <paul.k.romano@gmail.com>

docs/source/methods/depletion.rst

@@ -108,7 +108,8 @@ transport-coupled depletion, the expense is driven almost entirely by the time
 to compute a transport solution, i.e., to evaluate :math:`\mathbf{A}` for a
 given :math:`\mathbf{n}`. Thus, the cost of a method scales with the number of
 :math:`\mathbf{A}` evaluations that are performed per timestep. On the other
-hand, methods that require more evaluations generally achieve higher accuracy. The predictor method only requires one evaluation and its error converges as
+hand, methods that require more evaluations generally achieve higher accuracy.
+The predictor method only requires one evaluation and its error converges as
 :math:`\mathcal{O}(h)`. The CE/CM method requires two evaluations and is thus
 twice as expensive as the predictor method, but achieves an error of
 :math:`\mathcal{O}(h^2)`. An exhaustive description of time integration methods

docs/source/pythonapi/deplete.rst

@@ -12,10 +12,11 @@ Primary API
 The two primary requirements to perform depletion with :mod:`openmc.deplete`
 are:
 
-    1) A transpor operator
+    1) A transport operator
     2) A time-integration scheme
 
-The former is responsible for calcuating and retaining important information required for depletion. The most common examples are reaction rates and power
+The former is responsible for calculating and retaining important information
+required for depletion. The most common examples are reaction rates and power
 normalization data. The latter is responsible for projecting reaction rates and
 compositions forward in calendar time across some step size :math:`\Delta t`,
 and obtaining new compositions given a power or power density. The

docs/source/usersguide/depletion.rst

@@ -37,7 +37,8 @@ time::
     time, keff = results.get_keff()
 
 Note that the coupling between the reaction rate solver and the transmutation
-solver happens in-memory rather than by reading/writing files on disk. OpenMC has two categories of transport operators for obtaining transmutation reaction
+solver happens in-memory rather than by reading/writing files on disk. OpenMC
+has two categories of transport operators for obtaining transmutation reaction
 rates. 
 
 .. _coupled-depletion:
@@ -195,7 +196,7 @@ across all material instances.
 Transport-independent depletion
 ===============================
 
-.. note::
+.. warning::
    
    This feature is still under heavy development and has yet to be rigorously 
    verified. API changes and feature additions are possible and likely in
@@ -218,7 +219,7 @@ and a path to a depletion chain file::
     micro_xs = openmc.deplete.MicroXS()
     ...
 
-    op = IndependentOperator(materials, micro_xs, chain_file)
+    op = openmc.deplete.IndependentOperator(materials, micro_xs, chain_file)
 
 .. note::
 
@@ -270,8 +271,10 @@ Users can generate the one-group microscopic cross sections needed by
 
 The :meth:`~openmc.deplete.MicroXS.from_model()` method will produce a
 :class:`~openmc.deplete.MicroXS` object with microscopic cross section data in
-units of ``b``, which is what :class:`~openmc.deplete.IndependentOperator`
-expects the units to be. The :class:`~openmc.deplete.MicroXS` class also includes functions to read in cross section data directly from a ``.csv`` file or from data arrays::
+units of barns, which is what :class:`~openmc.deplete.IndependentOperator`
+expects the units to be. The :class:`~openmc.deplete.MicroXS` class also
+includes functions to read in cross section data directly from a ``.csv`` file
+or from data arrays::
 
     micro_xs = MicroXS.from_csv(micro_xs_path)