fix some docs links

Author: zingale

docs/source/advection_basics.rst

@@ -16,7 +16,7 @@ with different spatial and temporal intergration schemes.
 ``advection`` solver
 --------------------
 
-:py:mod:`advection` implements the directionally unsplit corner
+:py:mod:`pyro.advection` implements the directionally unsplit corner
 transport upwind algorithm :cite:`colella:1990` with piecewise linear reconstruction.
 This is an overall second-order accurate method, with timesteps restricted
 by 
@@ -33,7 +33,7 @@ The parameters for this solver are:
 ``advection_fv4`` solver
 ------------------------
 
-:py:mod:`advection_fv4` uses a fourth-order accurate finite-volume
+:py:mod:`pyro.advection_fv4` uses a fourth-order accurate finite-volume
 method with RK4 time integration, following the ideas in
 :cite:`mccorquodalecolella`.  It can be thought of as a
 method-of-lines integration, and as such has a slightly more restrictive
@@ -53,7 +53,7 @@ The parameters for this solver are:
 ``advection_nonuniform`` solver
 -------------------------------
 
-:py:mod:`advection_nonuniform` models advection with a non-uniform
+:py:mod:`pyro.advection_nonuniform` models advection with a non-uniform
 velocity field.  This is used to implement the slotted disk problem
 from :cite:`ZALESAK1979335`.  The basic method is similar to the
 algorithm used by the main ``advection`` solver.
@@ -65,7 +65,7 @@ The paramters for this solver are:
 ``advection_rk`` solver
 -----------------------
 
-:py:mod:`advection_rk` uses a method of lines time-integration
+:py:mod:`pyro.advection_rk` uses a method of lines time-integration
 approach with piecewise linear spatial reconstruction for linear
 advection.  This is overall second-order accurate, so it represents a
 simpler algorithm than the ``advection_fv4`` method (in particular, we
@@ -79,7 +79,7 @@ The parameter for this solver are:
 ``advection_weno`` solver
 -------------------------
 
-:py:mod:`advection_weno` uses a WENO reconstruction and method of
+:py:mod:`pyro.advection_weno` uses a WENO reconstruction and method of
 lines time-integration
 
 

docs/source/compressible_basics.rst

@@ -29,7 +29,7 @@ direction is allowed.
 ``compressible`` solver
 -----------------------
 
-:py:mod:`compressible` is based on a directionally unsplit (the corner
+:py:mod:`pyro.compressible` is based on a directionally unsplit (the corner
 transport upwind algorithm) piecewise linear method for the Euler
 equations, following :cite:`colella:1990`.  This is overall second-order
 accurate.
@@ -41,7 +41,7 @@ The parameters for this solver are:
 ``compressible_rk`` solver
 --------------------------
 
-:py:mod:`compressible_rk` uses a method of lines time-integration
+:py:mod:`pyro.compressible_rk` uses a method of lines time-integration
 approach with piecewise linear spatial reconstruction for the Euler
 equations.  This is overall second-order accurate.
 
@@ -52,7 +52,7 @@ The parameters for this solver are:
 ``compressible_fv4`` solver
 ---------------------------
 
-:py:mod:`compressible_fv4` uses a 4th order accurate method with RK4
+:py:mod:`pyro.compressible_fv4` uses a 4th order accurate method with RK4
 time integration, following :cite:`mccorquodalecolella`.
 
 The parameter for this solver are:
@@ -63,9 +63,9 @@ The parameter for this solver are:
 ``compressible_sdc`` solver
 ---------------------------
 
-:py:mod:`compressible_sdc` uses a 4th order accurate method with
+:py:mod:`pyro.compressible_sdc` uses a 4th order accurate method with
 spectral-deferred correction (SDC) for the time integration.  This
-shares much in common with the :py:mod:`compressible_fv4` solver, aside from
+shares much in common with the :py:mod:`pyro.compressible_fv4` solver, aside from
 how the time-integration is handled.
 
 The parameters for this solver are:
@@ -78,12 +78,12 @@ Example problems
 
 .. note::
 
-   The 4th-order accurate solver (:py:mod:`compressible_fv4`) requires that
+   The 4th-order accurate solver (:py:mod:`pyro.compressible_fv4`) requires that
    the initialization create cell-averages accurate to 4th-order.  To
    allow for all the solvers to use the same problem setups, we assume
    that the initialization routines initialize cell-centers (which is
    fine for 2nd-order accuracy), and the
-   :func:`preevolve() <compressible_fv4.simulation.Simulation.preevolve>` method will convert
+   :func:`preevolve() <pyro.compressible_fv4.simulation.Simulation.preevolve>` method will convert
    these to cell-averages automatically after initialization.
 
 

docs/source/design.rst

@@ -141,9 +141,6 @@ time you run the same bit of code, Numba will use the saved version rather than
 compiling the code again, saving some compilation time at the start of the
 simulation.
 
-.. note::
-
-    Because we have chosen to cache the compiled code, Numba will save it in the ``__pycache__`` directories. If you change the code, a new version will be compiled and saved, but the old version will not be deleted. Over time, you may end up with many unneeded files saved in the ``__pycache__`` directories. To clean up these files, you can run ``./mk.sh clean`` in the main ``pyro2`` directory. 
 
 Main driver
 -----------

docs/source/diffusion_basics.rst

@@ -7,7 +7,7 @@ pyro solves the constant-conductivity diffusion equation:
 
    \frac{\partial \phi}{\partial t} = k \nabla^2 \phi
 
-This is done implicitly using multigrid, using the solver :py:mod:`diffusion`.
+This is done implicitly using multigrid, using the solver :py:mod:`pyro.diffusion`.
 
 The diffusion equation is discretized using Crank-Nicolson
 differencing (this makes the diffusion operator time-centered) and the

docs/source/mesh_basics.rst

@@ -8,15 +8,15 @@ discretization. The basic theory of such methods is discussed in
 .. note::
 
    The core data structure that holds data on the grid is
-   :func:`CellCenterData2d <mesh.patch.CellCenterData2d>`.  This does
+   :func:`CellCenterData2d <pyro.mesh.patch.CellCenterData2d>`.  This does
    not distinguish between cell-centered data and cell-averages.  This
    is fine for methods that are second-order accurate, but for
-   higher-order methods, the :func:`FV2d <mesh.fv.FV2d>` class has
+   higher-order methods, the :func:`FV2d <pyro.mesh.fv.FV2d>` class has
    methods for converting between the two data centerings.
 
 
-:mod:`mesh.patch <mesh.patch>` implementation and use
------------------------------------------------------
+:mod:`mesh.patch <pyro.mesh.patch>` implementation and use
+----------------------------------------------------------
 
 We import the basic mesh functionality as:
 
@@ -29,38 +29,38 @@ We import the basic mesh functionality as:
 
 There are several main objects in the patch class that we interact with:
 
-* :func:`patch.Grid2d <mesh.patch.Grid2d>`: this is the main grid
+* :func:`patch.Grid2d <pyro.mesh.patch.Grid2d>`: this is the main grid
   object. It is basically a container that holds the number of zones
   in each coordinate direction, the domain extrema, and the
   coordinates of the zones themselves (both at the edges and center).
 
-* :func:`patch.CellCenterData2d <mesh.patch.CellCenterData2d>`: this
+* :func:`patch.CellCenterData2d <pyro.mesh.patch.CellCenterData2d>`: this
   is the main data object—it holds cell-centered data on a grid.  To
-  build a :func:`patch.CellCenterData2d <mesh.patch.CellCenterData2d>`
-  object you need to pass in the :func:`patch.Grid2d <mesh.patch.Grid2d>`
+  build a :func:`patch.CellCenterData2d <pyro.mesh.patch.CellCenterData2d>`
+  object you need to pass in the :func:`patch.Grid2d <pyro.mesh.patch.Grid2d>`
   object that defines the mesh. The
-  :func:`patch.CellCenterData2d <mesh.patch.CellCenterData2d>` object then
+  :func:`patch.CellCenterData2d <pyro.mesh.patch.CellCenterData2d>` object then
   allocates storage for the unknowns that live on the grid. This class
   also provides methods to fill boundary conditions, retrieve the data
   in different fashions, and read and write the object from/to disk.
 
-* :func:`fv.FV2d <mesh.fv.FV2d>`: this is a special class derived from
-  :func:`patch.CellCenterData2d <mesh.patch.CellCenterData2d>` that implements some extra functions
+* :func:`fv.FV2d <pyro.mesh.fv.FV2d>`: this is a special class derived from
+  :func:`patch.CellCenterData2d <pyro.mesh.patch.CellCenterData2d>` that implements some extra functions
   needed to convert between cell-center data and averages with
   fourth-order accuracy.
 
-* :func:`bnd.BC <mesh.boundary.BC>`: This is simply a container that
+* :func:`bnd.BC <pyro.mesh.boundary.BC>`: This is simply a container that
   holds the names of the boundary conditions on each edge of the
   domain.
 
-* :func:`ai.ArrayIndexer <mesh.array_indexer.ArrayIndexer>`: This is a
+* :func:`ai.ArrayIndexer <pyro.mesh.array_indexer.ArrayIndexer>`: This is a
   class that subclasses the NumPy ndarray and makes the data in the
   array know about the details of the grid it is defined on. In
   particular, it knows which cells are valid and which are the ghost
   cells, and it has methods to do the :math:`a_{i+1,j}` operations that are
   common in difference methods.
 
-* :func:`integration.RKIntegrator <mesh.integration.RKIntegrator>`:
+* :func:`integration.RKIntegrator <pyro.mesh.integration.RKIntegrator>`:
   This class implements Runge-Kutta integration in time by managing a
   hierarchy of grids at different time-levels.  A Butcher tableau
   provides the weights and evaluation points for the different stages
@@ -101,14 +101,14 @@ Jupyter notebook
 
 A Jupyter notebook that illustrates some of the basics of working with
 the grid is provided as `mesh-examples.ipynb <https://github.com/python-hydro/pyro2/blob/main/mesh/mesh-examples.ipynb>`_. This will
-demonstrate, for example, how to use the :func:`ArrayIndexer <mesh.array_indexer.ArrayIndexer>` methods to
+demonstrate, for example, how to use the :func:`ArrayIndexer <pyro.mesh.array_indexer.ArrayIndexer>` methods to
 construct differences.
 
 
 Tests
 -----
 
-The actual filling of the boundary conditions is done by the :func:`fill_BC <mesh.patch.CellCenterData2d.fill_BC>`
+The actual filling of the boundary conditions is done by the :func:`fill_BC <pyro.mesh.patch.CellCenterData2d.fill_BC>`
 method. The script ``bc_demo.py`` tests the various types of boundary
 conditions by initializing a small grid with sequential data, filling
 the BCs, and printing out the results.

docs/source/multigrid_basics.rst

@@ -8,16 +8,16 @@ of grids. Chapter 9 of the `pdf notes <http://bender.astro.sunysb.edu/hydro_by_e
 
 There are three solvers:
 
-* The core solver, provided in the class :func:`MG.CellCenterMG2d <multigrid.MG.CellCenterMG2d>` solves constant-coefficient Helmholtz problems of the form
+* The core solver, provided in the class :func:`MG.CellCenterMG2d <pyro.multigrid.MG.CellCenterMG2d>` solves constant-coefficient Helmholtz problems of the form
   :math:`(\alpha - \beta \nabla^2) \phi = f`
 
-* The class :func:`variable_coeff_MG.VarCoeffCCMG2d <multigrid.variable_coeff_MG.VarCoeffCCMG2d>` solves variable coefficient Poisson problems of the form
+* The class :func:`variable_coeff_MG.VarCoeffCCMG2d <pyro.multigrid.variable_coeff_MG.VarCoeffCCMG2d>` solves variable coefficient Poisson problems of the form
   :math:`\nabla \cdot (\eta \nabla \phi ) = f`.  This class inherits the core functionality from ``MG.CellCenterMG2d``.
 
-* The class :func:`general_MG.GeneralMG2d <multigrid.general_MG.GeneralMG2d>` solves a general elliptic
+* The class :func:`general_MG.GeneralMG2d <pyro.multigrid.general_MG.GeneralMG2d>` solves a general elliptic
   equation of the form :math:`\alpha \phi + \nabla \cdot ( \beta
   \nabla \phi) + \gamma \cdot \nabla \phi = f`.  This class inherits
-  the core functionality from :func:`MG.CellCenterMG2d <multigrid.MG.CellCenterMG2d>`.
+  the core functionality from :func:`MG.CellCenterMG2d <pyro.multigrid.MG.CellCenterMG2d>`.
 
   This solver is the only one to support inhomogeneous boundary
   conditions.

docs/source/output.rst

@@ -39,7 +39,7 @@ Several simply utilities exist to operate on output files
 Reading and plotting manually
 -----------------------------
 
-pyro output data can be read using the :func:`util.io_pyro.read <util.io_pyro.read>` method. The following
+pyro output data can be read using the :func:`util.io_pyro.read <pyro.util.io_pyro.read>` method. The following
 sequence (done in a python session) reads in stored data (from the
 compressible Sedov problem) and plots data falling on a line in the x
 direction through the y-center of the domain (note: this will include

docs/source/particles_basics.rst

@@ -3,8 +3,8 @@ Particles
 
 A solver for modelling particles.
 
-:mod:`particles.particles <particles.particles>` implementation and use
------------------------------------------------------------------------
+:mod:`particles.particles <pyro.particles.particles>` implementation and use
+----------------------------------------------------------------------------
 
 We import the basic particles module functionality as:
 
@@ -14,9 +14,9 @@ We import the basic particles module functionality as:
 
 The particles solver is made up of two classes:
 
-* :func:`Particle <particles.particles.Particle>`, which holds
+* :func:`Particle <pyro.particles.particles.Particle>`, which holds
   the data about a single particle (its position and velocity);
-* :func:`Particles <particles.particles.Particles>`, which holds the data
+* :func:`Particles <pyro.particles.particles.Particles>`, which holds the data
   about a collection of particles.
 
 The particles are stored as a dictionary, and their positions are updated
@@ -27,20 +27,20 @@ function without otherwise affecting the behaviour of the module).
 
 The particles can be initialized in a number of ways:
 
-* :func:`randomly_generate_particles <particles.particles.Particles.randomly_generate_particles>`,
+* :func:`randomly_generate_particles <pyro.particles.particles.Particles.randomly_generate_particles>`,
   which randomly generates ``n_particles`` within the domain.
-* :func:`grid_generate_particles <particles.particles.Particles.grid_generate_particles>`,
+* :func:`grid_generate_particles <pyro.particles.particles.Particles.grid_generate_particles>`,
   which will generate approximately ``n_particles`` equally spaced in the
   x-direction and y-direction (note that it uses the same number of particles in
   each direction, so the spacing will be different in each direction if the
   domain is not square). The number of particles will be increased/decreased
   in order to fill the whole domain.
-* :func:`array_generate_particles <particles.particles.Particles.array_generate_particles>`,
+* :func:`array_generate_particles <pyro.particles.particles.Particles.array_generate_particles>`,
   which generates particles based on array of particle positions passed to the
   constructor.
 * The user can define their own ``particle_generator`` function and pass this into the
-  :func:`Particles <particles.particles.Particles>` constructor. This function takes the number of particles to be
-  generated and returns a dictionary of :func:`Particle <particles.particles.Particle>` objects.
+  :func:`Particles <pyro.particles.particles.Particles>` constructor. This function takes the number of particles to be
+  generated and returns a dictionary of :func:`Particle <pyro.particles.particles.Particle>` objects.
 
 We can turn on/off the particles solver using the following runtime paramters:
 
@@ -95,7 +95,7 @@ in as arguments to this function as they cannot be accessed using the standard
 Plotting particles
 ------------------
 
-Given the :func:`Particles <particles.particles.Particles>` object ``particles``, we can plot the particles by getting
+Given the :func:`Particles <pyro.particles.particles.Particles>` object ``particles``, we can plot the particles by getting
 their positions using
 
 .. code-block:: python
@@ -128,7 +128,7 @@ x-position, we can plot them on the figure axis ``ax`` using the following code:
       ax.set_xlim([myg.xmin, myg.xmax])
       ax.set_ylim([myg.ymin, myg.ymax])
 
-Applying this to the Kelvin-Helmholtz problem with the :mod:`compressible <compressible>` solver,
+Applying this to the Kelvin-Helmholtz problem with the :mod:`compressible <pyro.compressible>` solver,
 we can produce a plot such as the one below, where the particles have been
 plotted on top of the fluid density.
 

docs/source/running.rst

@@ -3,7 +3,7 @@ Running
 
 Pyro can be run in two ways: either from the commandline, using the ``pyro_sim.py``
 script and passing in the solver, problem and inputs as arguments, or by using
-the :func:`Pyro <pyro_sim.pyro>` class.
+the :func:`Pyro <pyro.pyro_sim.pyro>` class.
 
 Commandline
 ------------
@@ -49,16 +49,16 @@ above run, we could do:
 Pyro class
 ----------
 
-Alternatively, pyro can be run using the :func:`Pyro <pyro_sim.pyro>` class. This provides
+Alternatively, pyro can be run using the :func:`Pyro <pyro.pyro_sim.Pyro>` class. This provides
 an interface that enables simulations to be set up and run in a Jupyter notebook -- see
 ``examples/examples.ipynb`` for an example notebook. A simulation can be set up and run
 by carrying out the following steps:
 
-* create a :func:`Pyro <pyro_sim.pyro>` object, initializing it with a specific solver
+* create a :func:`Pyro <pyro.pyro_sim.Pyro>` object, initializing it with a specific solver
 * initialize the problem, passing in runtime parameters and inputs
 * run the simulation
 
-For example, if we wished to use the :mod:`compressible <compressible>` solver to run the
+For example, if we wished to use the :mod:`compressible <pyro.compressible>` solver to run the
 Kelvin-Helmholtz problem ``kh``, we would do the following:
 
 .. code-block:: python
@@ -71,7 +71,7 @@ Kelvin-Helmholtz problem ``kh``, we would do the following:
 
 Instead of using an inputs file to define the problem parameters, we can define a
 dictionary of parameters and pass them into the :func:`initialize_problem
-<pyro_sim.pyro.initialize_problem>` function using the keyword argument ``inputs_dict``.
+<pyro.pyro_sim.Pyro.initialize_problem>` function using the keyword argument ``inputs_dict``.
 If an inputs file is also passed into the function, the parameters in the dictionary
 will override any parameters in the file. For example, if we wished to turn off
 visualization for the previous example, we would do:
@@ -84,8 +84,8 @@ visualization for the previous example, we would do:
                             inputs_dict=parameters)
 
 It's possible to evolve the simulation forward timestep by timestep manually using
-the :func:`single_step <pyro_sim.pyro.single_step>` function (rather than allowing
-:func:`run_sim <pyro_sim.pyro.run_sim>` to do this for us). To evolve our example
+the :func:`single_step <pyro.pyro_sim.Pyro.single_step>` function (rather than allowing
+:func:`run_sim <pyro.pyro_sim.Pyro.run_sim>` to do this for us). To evolve our example
 simulation forward by a single step, we'd run
 
 .. code-block:: python
@@ -117,7 +117,7 @@ default value of any of these previously defined
 parameters. Additionally, any parameter can be specified at the end of
 the commandline, and these will be used to override the defaults. The
 collection of runtime parameters is stored in a
-:func:`RuntimeParameters <util.runparams.RuntimeParameters>` object.
+:func:`RuntimeParameters <pyro.util.runparams.RuntimeParameters>` object.
 
 The ``runparams.py`` module in ``util/`` controls access to the runtime
 parameters. You can setup the runtime parameters, parse an inputs