Various fixes and updates in documentation

docs/source/usersguide/cross_sections.rst

@@ -16,10 +16,10 @@ recommended to use one of the pregenerated libraries. Alternatively, if you have
 ACE format data that was produced with NJOY_, such as that distributed with
 MCNP_ or Serpent_, it can be converted to the HDF5 format using the :ref:`using
 the Python API <create_xs_library>`. Several sources provide openly available
-ACE data including the `ENDF/B`_, JEFF_, and TENDL_
-libraries. In addition to tabulated cross sections in the HDF5 files, OpenMC
-relies on :ref:`windowed multipole <windowed_multipole>` data to perform
-on-the-fly Doppler broadening.
+ACE data including the `ENDF/B`_, JEFF_, and TENDL_ libraries as well as the
+`LANL Nuclear Data Team <https://nucleardata.lanl.gov/>`_. In addition to
+tabulated cross sections in the HDF5 files, OpenMC relies on :ref:`windowed
+multipole <windowed_multipole>` data to perform on-the-fly Doppler broadening.
 
 In multi-group mode, OpenMC utilizes an HDF5-based library format which can be
 used to describe nuclide- or material-specific quantities.
@@ -30,11 +30,11 @@ Environment Variables
 
 When :ref:`scripts_openmc` is run, it will look for several environment
 variables that indicate where cross sections can be found. While the location of
-cross sections can also be indicated through the :class:`openmc.Materials` class
-(or in the :ref:`materials.xml <io_materials>` file), if you always use the same
-set of cross section data, it is often easier to just set an environment
-variable that will be picked up by default every time OpenMC is run. The
-following environment variables are used:
+cross sections can also be indicated through the
+:attr:`openmc.Materials.cross_setion` attribute (or in the :ref:`materials.xml
+<io_materials>` file), if you always use the same set of cross section data, it
+is often easier to just set an environment variable that will be picked up by
+default every time OpenMC is run. The following environment variables are used:
 
 :envvar:`OPENMC_CROSS_SECTIONS`
   Indicates the path to the :ref:`cross_sections.xml <io_cross_sections>`

docs/source/usersguide/geometry.rst

@@ -121,11 +121,11 @@ For many regions, a bounding-box can be determined automatically::
 While a bounding box can be determined for regions involving half-spaces of
 spheres, cylinders, and axis-aligned planes, it generally cannot be determined
 if the region involves cones, non-axis-aligned planes, or other exotic
-second-order surfaces. For example, the :func:`openmc.get_hexagonal_prism`
+second-order surfaces. For example, the :func:`openmc.model.hexagonal_prism`
 function returns the interior region of a hexagonal prism; because it is bounded
 by a :class:`openmc.Plane`, trying to get its bounding box won't work::
 
-  >>> hex = openmc.get_hexagonal_prism()
+  >>> hex = openmc.model.hexagonal_prism()
   >>> hex.bounding_box
   (array([-0.8660254,       -inf,       -inf]),
    array([ 0.8660254,        inf,        inf]))
@@ -374,7 +374,7 @@ code would work::
   hexlat.universes = [outer_ring, middle_ring, inner_ring]
 
 If you need to create a hexagonal boundary (composed of six planar surfaces) for
-a hexagonal lattice, :func:`openmc.get_hexagonal_prism` can be used.
+a hexagonal lattice, :func:`openmc.model.hexagonal_prism` can be used.
 
 .. _usersguide_geom_export:
 
@@ -396,6 +396,13 @@ if needed, lattices, the last step is to create an instance of
    geom.root_universe = root_univ
    geom.export_to_xml()
 
+Note that it's not strictly required to manually create a root universe. You can
+also pass a list of cells to the :class:`openmc.Geometry` constructor and it
+will handle creating the unverse::
+
+   geom = openmc.Geometry([cell1, cell2, cell3])
+   geom.export_to_xml()
+
 .. _constructive solid geometry: https://en.wikipedia.org/wiki/Constructive_solid_geometry
 .. _quadratic surfaces: https://en.wikipedia.org/wiki/Quadric
 

docs/source/usersguide/settings.rst

@@ -221,26 +221,11 @@ selected::
 
   settings.electron_treatment = 'led'
 
-.. warning::
-   Currently, collision stopping powers used in the TTB approximation come from
-   the `NIST ESTAR database`_, which provides data for each element calculated
-   using by default the material density at standard temperature and pressure.
-   In OpenMC, stopping powers for compounds are calculated from this elemental
-   data using Bragg's additivity rule. However, this is not a good
-   approximation --- the collision stopping power is a function of certain
-   quantities, such as the mean excitation energy and particularly the density
-   effect correction, that depend on material properties. Data for constituent
-   elements in a compound cannot simply be summed together, but rather these
-   quantities should be calculated for the material. This treatment will be
-   especially poor when the density of a material is different from the
-   densities used in the NIST data.
-
 .. note::
    Some features related to photon transport are not currently implemented,
    including:
 
      * Tallying photon energy deposition.
-     * Properly accounting for energy deposition in coupled n-p calculations.
      * Generating a photon source from a neutron calculation that can be used
        for a later fixed source photon calculation.
      * Photoneutron reactions.