Merge pull request #35 from Json-To-String/doc-updates

Typos

Author: dihm

docs/source/api/api_index.rst

@@ -1,4 +1,4 @@
-API Documenation
+API Documentation
 =================
 
 .. autosummary::

docs/source/changelog.rst

@@ -29,10 +29,10 @@ v2.1.0
 Improvements
 ++++++++++++
 
-- Fully support 1D/2D/3D doppler solves using the analytic-enabled solver, `solve_doppler_analytic`. The anlytic average
+- Fully support 1D/2D/3D doppler solves using the analytic-enabled solver, `solve_doppler_analytic`. The analytic average
   is applied to a single dimension, with other present dimensions treated numerically. This provides notable decreases in
   computation times and memory footprints and increases in solution accuracy in all spatial dimensions.
-- Added an example notebook, `Analyic Doppler Solver`, showcasing the new `solve_doppler_analytic`.
+- Added an example notebook, `Analytic Doppler Solver`, showcasing the new `solve_doppler_analytic`.
 - Extended documentation and unit unit-testing to include hybrid solver implementation.
 
 Deprecations
@@ -188,7 +188,7 @@ Improvements
 
 - Level diagrams now use `Sensor.get_rotating_frames` to provide better plotting of energy ordering of levels.
 - Level diagrams now allow for optional control of plotting parameters by manually specifying `ld_kw` options on nodes and edges.
-- Added the ability to specify energy level shifts (additional Hamiltonian digonal terms) not accounted for by the coupling infrastructure.
+- Added the ability to specify energy level shifts (additional Hamiltonian diagonal terms) not accounted for by the coupling infrastructure.
 
 
 Bug Fixes
@@ -210,8 +210,8 @@ v1.1.0
 Improvements
 ++++++++++++
 
-- Added the ability to specify hyperfine states in a `Cell`. They are distiguished by having 5 quantum numbers `[n, l, j, f, m_f]`.
-- `kappa` and `eta` are now proprties of `Cell` which are calculated on the fly.
+- Added the ability to specify hyperfine states in a `Cell`. They are distinguished by having 5 quantum numbers `[n, l, j, f, m_f]`.
+- `kappa` and `eta` are now properties of `Cell` which are calculated on the fly.
 - Separated rotating frame logic from hamiltonian diagonal generation into a new function `Sensor.get_rotating_frames()`.
   Allows for simple inspection of what rotating frame rydiqule is using in a solve.
 - Reworked the under-the-hood parameter zipping framework. This should have minimal impact on user-facing functionality.
@@ -264,7 +264,7 @@ Deprecations
   It is now `rabi_frequency` times the `time_dependence`.
 - Multiple sign errors have been corrected in `Sensor` and `Cell` with regards to detunings.
   Results that are asymmetric about zero detuning are likely to change.
-  Please ensure all couplings are following correct sign conventions for consisten results
+  Please ensure all couplings are following correct sign conventions for consistent results
   (ie second state of `states` tuple has higher energy).
 - most of the functions in experiments.py have been moved to become methods of `Solution` class.
 
@@ -304,7 +304,7 @@ Bug Fixes
 +++++++++
 
 - Changed an `isinstance` check to `hasattr`, fixing an occasional issue with reloading `rydiqule` in jupyter notebooks.
-- Fixed issue where submodules wree not installed outside of editable mode.
+- Fixed issue where submodules were not installed outside of editable mode.
 - Fixed a bug where additional arguments like warning suppression could not be passed to Sensor.add_couplings
 
 Deprecations
@@ -327,7 +327,7 @@ Bug Fixes
 +++++++++
 
 - Fixed issue where solvers would save doppler axes labels and values even when they are summed over to the solution object
-- Fixed a bug where energy level diagrams broke when decochernce rates were scanned.
+- Fixed a bug where energy level diagrams broke when decoherence rates were scanned.
 - Fixed issue where compiled timesolvers could not solve doppler averaged problems.
 - Fixed issue where certain doppler solves could not be sliced correctly
 
@@ -386,16 +386,16 @@ Improvements
 
   - Gamma matrix is now calculated on the fly with the `decoherence__matrix()` method.
   - Decoherent transitions are now added with with the `add_decoherence()` function in `Sensor`.
-  - `Cell` now calculates tranistion frequencies and decay rates automatically and places them on the appropriate graph edges.
+  - `Cell` now calculates transition frequencies and decay rates automatically and places them on the appropriate graph edges.
 
 - Changed the `Sensor.couplings` attribute from a `nx.Graph` to an `nx.DiGraph`. This has multiple advantages:
 
   - A less vague definition of detuning convention.
   - Precise definition of energy ordering: couplings now always point from lower to higher absolute energy.
-  - More flexibility in decoherence. Decoherent transions now point "from" one state "to" another rather than just "between" 2 states. This fixes a limitation where gamma matrices no longer must be lower triangular.
+  - More flexibility in decoherence. Decoherent transitions now point "from" one state "to" another rather than just "between" 2 states. This fixes a limitation where gamma matrices no longer must be lower triangular.
 
 - `get_snr()` function in `rq.experiments` now takes `kappa` and `eta` as optional arguments to allow for running on any `Sensor` object. They can still be inferred from a `Sensor` subclass that has them as attributes if unspecified.
-- time solver now properly handles complex time dependences in the rotating wave approximation
+- time solver now properly handles complex time dependencies in the rotating wave approximation
 - Added type hints to code base that can be used to static type check with mypy
 - Added functions `rq.calc_kappa` and `rq.calc_eta` to properly calculate kappa and eta constants for experimental parameters.
 - Added function `rq.get_OD` that calculates the optical depth of a solution
@@ -408,8 +408,8 @@ Bug Fixes
 - Fixed an issue with time dependence in the probe laser
 - Modified solver to allow for complex time dependence
 - Fixed non-hermitian hamiltonians in time solver
-- Fixed error with multiple time-dependences in time solver
-- Added functionality to solver error with complex time dependences
+- Fixed error with multiple time-dependencies in time solver
+- Added functionality to solver error with complex time dependencies
 - Modified experimental return functions (`get_transmission_coef()`, `get_phase_shift()`, and `get_susceptibility()``) to allow scanning of probe rabi frequency
 - Fixed `get_rho_ij` so that it correctly calculates the `(0,0)` population element
 - Fix error in `test_sensor_management` which fails if temporary directory does not exist.
@@ -432,7 +432,7 @@ v0.3.0
 Improvements
 ++++++++++++
 
-- Expanded documention
+- Expanded documentation
 - Removed restrictions on ARC and numpy versions during installation.
 - Vectorized equation of motion generation to support prepending axes to a hamiltonian
 - Updated the internal mechanism for sensor handling fields of various type
@@ -458,7 +458,7 @@ Improvements
 - Quantum numbers and absolute energies are now stored on the nodes of a Cell couplings graph
 - Cell now adds decay rates and decoherences to the nodes and edges of the Cell couplings graph
 - Cell now calculates the gamma matrix in an arbitrary way, and is no longer limited to two laser, ladder schemes
-- Added function to calculate sensor SNR with repect to any varied sensor coupling parameter
+- Added function to calculate sensor SNR with respect to any varied sensor coupling parameter
 - Added function to return sensor parameter mesh
 
 Bug Fixes
@@ -475,9 +475,9 @@ Deprecations
 
 - All "field" functionality are being deprecated in favor of "coupling"
 - The `rf_couplings`, `target_state`, and `rf_dipole_matrix` arguments of `solve_time()`
-- All functions relating to sensor.transtion_map are deprecated
+- All functions relating to sensor.transition_map are deprecated
 - Cell now does not accept gamma_excited or gamma_Rydberg as these are always calculated or Sensor can be used with a given gamma matrix
-- Cell now does not accept  gamma_doppler as Doppler broadening width is given by mutiplying the most proable velocity and the laser k-vector
+- Cell now does not accept  gamma_doppler as Doppler broadening width is given by multiplying the most probable velocity and the laser k-vector
 
 v0.2.0
 ------

docs/source/dev/docs.rst

@@ -2,7 +2,7 @@ Building the Documentation
 ==========================
 
 This section describes how to build the documentation locally.
-A web-hosted copy of the docs is avialable at `https://rydiqule.readthedocs.io/ <https://rydiqule.readthedocs.io/>`_
+A web-hosted copy of the docs is available at `https://rydiqule.readthedocs.io/ <https://rydiqule.readthedocs.io/>`_
 and should generally be used.
 These instructions are provided for local testing and development purposes.
 

docs/source/dev/tests.rst

@@ -33,7 +33,7 @@ For example, this command will only run tests relating to the steady state solvi
   pytest -m steady_state
 
 You can also exclude a specific group of tests.
-For example, this command will exlcude tests marked as slow.
+For example, this command will exclude tests marked as slow.
 
 .. code-block:: shell
 
@@ -68,7 +68,7 @@ The markers we use are
   * - experiments
     - Marks a test that represents a full experiment.
   * - util
-    - Marks a test of the ancillary utilties.
+    - Marks a test of the ancillary utilities.
   * - structure
     - Marks a test of the definition of the atomic system.
   * - exception

docs/source/dev/types.rst

@@ -10,7 +10,7 @@ The easiest way to use this checker locally is via the VS Code Pylance extension
 which defaults to the pyright type checker and will automatically run when configuration options are detected in the root `pyproject.toml`.
 
 Note that python is still a dynamic, duck-typed language,
-and rydiqule employs some features that are perfectly valid python which are not expressable in the type hinting system.
+and rydiqule employs some features that are perfectly valid python which are not expressible in the type hinting system.
 In these situations, we err on the side of type hints being primarily documentation,
 and do our best to not obfuscate functioning code merely to satisfy the type checker.
 

docs/source/writeups/doppler.rst

@@ -38,7 +38,7 @@ meaning all Doppler shifts are due to velocities projected along a single axis.
 Choosing which velocity classes to calculate when performing doppler averaging is a fairly complex meshing problem.
 Our ultimate goal is to numerically approximate a continuous integral in one to three dimensions using a discrete sum approximation.
 For thermal vapors, where the spread of doppler velocities is large,
-resulting in Doppler shifts much greater than other detunings, linewidths, or Rabi frequenices in the problem,
+resulting in Doppler shifts much greater than other detunings, linewidths, or Rabi frequencies in the problem,
 most velocity classes only contribute minor incoherent absorption to the final result.
 This allows for much coarser meshes.
 The difficulty lies in determining which velocity classes, a-priori, can participate in generally narrow coherent processes.

docs/source/writeups/eom_notes.rst

@@ -44,7 +44,7 @@ Equations of Motion
 -------------------
 
 The Master equation that governs system dynamics used by Rydiqule is the `Linbladian <https://en.wikipedia.org/wiki/Lindbladian>`_.
-It is a semi-classical formulation of the Schoedinger equation for use in open quantum systems.
+It is a semi-classical formulation of the Schroedinger equation for use in open quantum systems.
 
 .. math:: \dot{\rho} = -\frac{i}{\hbar}[H,\rho]-\mathcal{L}
 

docs/source/writeups/nlj.rst

@@ -32,7 +32,7 @@ which has a similar role and dependencies as :math:`m_j` in a fine structure sta
 
 In a Rydberg atom, the hyperfine structure of the ground states and first few excited states is resolveable
 (though often obscured by doppler averaging in a thermal ensemble).
-As a result, these states are typicaly defined by :math:`|n,l,j,f,m_f\rangle`.
+As a result, these states are typically defined by :math:`|n,l,j,f,m_f\rangle`.
 This interaction is much less strong for Rydberg states,
 so the appropriate quantum numbers to use are the fine structure
 :math:`|n,l,j,m_j\rangle`.
@@ -69,7 +69,7 @@ may be due to stray fields.
 
     Level diagram of 2-photon Rydberg EIT system using the degenerate sublevels approximation.
 
-A subtlty to using this approximation is in defining the dipole moment of a transition.
+A subtlety to using this approximation is in defining the dipole moment of a transition.
 The dipole moment depends on the magnetic sublevels of either state, which are ignored by the approximation.
 When the sublevels are degenerate, any sublevel with population in it will contribute to an average coupling
 based on the dipole-allowed transitions.

docs/source/writeups/stacking_conventions.rst

@@ -1,7 +1,7 @@
 Stacking Conventions
 ====================
 
-For many probelms, Rydiqule is designed to implicitly handle multiple possible values for a
+For many problems, Rydiqule is designed to implicitly handle multiple possible values for a
 single parameter. For example, sweeping over a range of detuning values is handled in Rydiqule
 simply by specifying the value of interest a list or array rather than a single value. This
 enables a tremendous amount of flexibility in the problems that Rydiqule can solve naturally,
@@ -17,7 +17,7 @@ with how fast elements are accessed from that list and operating on. `Numpy arra
 were created to address this limitation and Rydiqule makes extensive use of them to make
 its calculations fast without losing the ease-of-use benefits of a Python interface. Fundamentally,
 a numpy ``ndarray`` is a grid of numbers that has dimensionality `m1` by `m2` by `m3` and so on.
-Numpy routines are written to operate on these arrays very quickls for large numbers of dimensions.
+Numpy routines are written to operate on these arrays very quickly for large numbers of dimensions.
 
 Stacking
 --------
@@ -31,7 +31,7 @@ matrices. This is the array that would be generated if a list of 25 values were
 detuning value in a 3-level `Sensor`, and that `Sensor`'s `get_hamiltonian` function were called.
 Rydiqule seamlessly handles all the work of generating those Hamiltonian matrices for each value, and returns
 a single array object as an output. Similarly, if 2 values are specified as lists of length 25, 
-a single arary of shape ``(25, 25, 3, 3)`` would be returned, with a different :math:`3\times 3`
+a single array of shape ``(25, 25, 3, 3)`` would be returned, with a different :math:`3\times 3`
 Hamiltonian matrix for every combination of parameter values, for a total of 625 Hamiltonian matrices. 
 Rydiqule terms this array a "stack" of Hamiltonians, and the "stack shape" are the axes preceding the actual
 matrix value axes (in this case ``(25, 25)``), and is typically, denoted in Rydiqule as ``*l`` to
@@ -40,8 +40,8 @@ make clear that it could be any length of set of values depending on the problem
 Hamiltonian generations is created using this convention, and that carries through to generation of 
 equations of motion, and any other quantities that may have a different matrix for each parameter
 value. A Hamiltonian stack of shape ``(*l, 3, 3)`` will generate an equation of motion (eom) stack
-of shape ``(*l, 8, 8)``, with all stack demensions remaining consistent. Rydiqule's internals
-are, broadly, agnostic to exaclty what the dimensions ``*l`` represent, and work regardless, as long as the
+of shape ``(*l, 8, 8)``, with all stack dimensions remaining consistent. Rydiqule's internals
+are, broadly, agnostic to exactly what the dimensions ``*l`` represent, and work regardless, as long as the
 dimensions corresponding to the actual quantities are in the expected position at the end.
 
 Parameter Ordering
@@ -50,19 +50,19 @@ Parameter Ordering
 Given that any number of parameters may be defined as a list, Rydiqule needs a convention to ensure, in the final
 result, the values represent what is expected and has not been turned around. It is important to Rydiqule's
 design philosophy that internal variables not by tracked opaquely, and that quantities are, to the extent
-possible, generated on the fly in a predictable and reprodicuble way. This begs the questions, which
+possible, generated on the fly in a predictable and reproducible way. This begs the questions, which
 axis corresponds to which value? Suppose the coupling between states 0 and 1 is swept in detuning over 25
 values, as is the coupling between states 1 and 2, the stack shape will be ``(25, 25)``, but there 
 are some uncertainties. One might assume that the first axis corresponds the the first laser, and the second
 axis corresponds to the second laser. However, this is not necessarily obvious, and it might be the other
 way around without a unifying convention. Rydiqule's solution to this problem turns out to be simple: python's
-``.sort()`` function. Since it always orders things accordning to the same rules, there is a predictable outcome
+``.sort()`` function. Since it always orders things according to the same rules, there is a predictable outcome
 to which axis is which. The parameters are represent by tuples: ``((0,1),"detuning")`` and ``((1,2),"detuning")``.
 ``.sort()`` will sort them first by the lower state of a transition, then by the upper state, then alphabetically by
 the string parameter name (in this case detuning for both). 
 
-With this simple convention, Rydiqule makes these arrays consistent accross functions. One can be sure that all 
-values will be exaclty what is expected and line up properly for all quantities. Hamiltonians, equations of motion,
+With this simple convention, Rydiqule makes these arrays consistent across functions. One can be sure that all 
+values will be exactly what is expected and line up properly for all quantities. Hamiltonians, equations of motion,
 and solutions will all use the same rules. To avoid figuring this out manually for every system, the ``Sensor`` module
 contains the ``.axis_labels()`` method, which returns a list of which axes are which in string form for
 results interpretation. Note that the internal functions which calculate these values don't actually care
@@ -75,7 +75,7 @@ It is worth a quick note how Rydiqule handles doppler broadening, because it lev
 around stacking as other parameter scans, and it may be encountered and cause confusion if you use Rydiqule
 enough. If doppler is accounted for in a solve, that typically is not invoked until the relevant ``solve`` 
 function is called. Given a case of ``n_doppler`` velocity classes in 1 dimension, a new axis will be prepended
-to the stack, resuling in a ``n_doppler`` new dopple-shifted Hamiltonian matrices matrix that was previously
+to the stack, resulting in a ``n_doppler`` new doppler-shifted Hamiltonian matrices matrix that was previously
 in the stack. Typically, this is done under the hood, and these other solutions are averaged over before
 a result is returned, but examining intermediate values may ultimately result in seeing these axes, even
 if they are not present in the solution that is returned. Importantly, the solver internals are still agnostic

docs/source/writeups/sublevels.rst

@@ -1,7 +1,7 @@
 Fine and Hyperfine Structure with Sublevels
 ===========================================
 
-In many situtations, accurate modeling requires solving for the entire atomic structure (i.e. explicit handling of the magnetic sublevels).
+In many situations, accurate modeling requires solving for the entire atomic structure (i.e. explicit handling of the magnetic sublevels).
 These situations include calculating changes in probing polarization and ellipticity angles,
 non-degenerate states due to ambient magnetic fields,
 or inhomogeneous coupling strengths due to sublevel structure.
@@ -267,7 +267,7 @@ The Clebsch-Gordon coefficients are related to the spherical matrix element by
 
     For example, :math:`\langle J=1/2, m_J=\pm1/2|d|J'=3/2, m_J'=\pm3/2\rangle` has `coherent_cc=1`.
 
-    Note, however, that :math:`\langle J=1/2, m_J=\pm1/2|d|J'=1/2, m_J'=\mp1/2\rangle` has `coherenct_cc=4/3`.
+    Note, however, that :math:`\langle J=1/2, m_J=\pm1/2|d|J'=1/2, m_J'=\mp1/2\rangle` has `coherent_cc=4/3`.
 
 
 HFS to HFS