Make consistency edits to documentation (#1158)

* Make consistency edits for index and installation docs pages.

* Remove spaces from and add comma to quickstart notebook.

* Ensure YAML and CSVY are all caps throughout the Model page.

* Add colon before list in ejecta model configuration page.

* Make YAML spelling consistent in power law density page.

* Make YAML spelling consistent in exponential density page.

* Add hyphens, commas, and make consistent capitalization in custom density page.

* Make consistent spaces inside units and add period to custom density notebook.

* Add spaces, commas, and move parens in uniform composition page.

* Ensure capitalization, add spaces, move parens, add periods to ASCII formatted custom composition page.

* Add em dashes, add periods, remove periods, make parameters code in configuration page.

* Add commas, capitalizations, periods, and code words to config validator page.

* Add comma and period to read_configuration notebook.

* Add periods, commas, bullet points, and capitalizations to atomic data description page.

* Add em dash and periods to command line run page.

* Add commas, capitalizations to tardis gui page.

* Add period and comma to interacting with TARDIS page.

* Make plural consistency on cmfgen page.

* Added colon before list in physics index page.

* Capitalize TARDIS, link external modules when necessary, add a few commas to plasma landing page.

* Add hyphens, capitalize a word, and correct a typo in the Monte Carlo energy packets page.

* Correct typos, add hyphens, move around commas in packet propagation page.

* Correct typos, move commas around in line interaction page.

* Correct typos, moved commas around in estimators page.

* Correct typos, move commas around for virtual packets page.

* Correct typos, move around commas for direct integration page.

* Correct typos and add commas to random sampling page.

* Correct typos in old monte carlo page.

* Fix latex error in old montecarlo

* Fix typos in LTE plasma plage

* Finish up neburlar plasma, make edits to macroactom.

* Correct typos, move commas, attempt latex fix for nlte page.

* Capitalize TARDIS in helium_nlte page.

* Add hyphen in code comparison page.

* Correct spelling of BibTeX.

* Correct spelling of AstroPy, adding a comma to developer workflow page.

* Correct capitalizations, correct typos, shuffle commas in running tests page.

* Correct a few more typos in running tests page.

* Change GitHub spelling on issues page

* Correct typos, commas, and capitalizations in git workflow page.

* Change AstroPy spelling in release workflow page.

* Add a period and shuffle commas in update refdata page.

* Add periods, correct capitalizations, correct typos, and shuffle commas in continuous integration page.

* Change AstroPy spelling, add period at end of developer faq page.

* Format bulleted list better in atomic data description page.

* Capitalize TARDIS; remove montecarlo primer from index, as it is included in the physics overview.

* Capitalize Python in installation page.

* Make final latex equation render correctly

* Reword a few lines in installation page.

* linking Anaconda in installation page

* Add link to CMFGEN reference

* Add period to montecarlo index

* Linking physics is incomplete to TARDIS project board

* did not correctly format links in .rst files

* Had not merged correctly!

* Missed a uncapitalized YAML

* Removed a few double spaces

* Bulleted list was not rendering correctly

* Converting AstroPy to Astropy

* Capitalize TARDIS in new doc notebook

docs/atomic/atomic_data_description.rst

@@ -6,8 +6,8 @@ Atomic Data Format Description
 .. currentmodule:: tardis.io.atomic
 
 
-The atomic data for tardis is stored in `hdf5 files <http://www.h5py.org/>`_. TARDIS ships with a
-relatively simple atomic dataset which only contains silicon lines and levels. TARDIS also has a full atomic dataset which contains
+The atomic data for tardis is stored in `HDF5 files <http://www.h5py.org/>`_. TARDIS ships with a
+relatively simple atomic dataset that only contains silicon lines and levels. TARDIS also has a full atomic dataset which contains
 the complete Kurucz dataset (`<http://kurucz.harvard.edu/LINELISTS/GFALL/>`_). This full dataset also contains recombination
 coefficients from the ground state (:math:`\zeta-\textrm{factor}` used in :ref:`calc_zeta_label`) and data for calculating the
 branching or macro atom line interaction (:ref:`macroatom`).
@@ -17,8 +17,8 @@ branching or macro atom line interaction (:ref:`macroatom`).
 HDF5 Dataset
 ------------
 
-As mentioned previously, all atomic data is stored in `hdf5 files <http://www.h5py.org/>`_  which contain tables
-that include mass, ionization, levels and lines data. The atom data that ships with TARDIS is located in data/atom
+As mentioned previously, all atomic data is stored in `HDF5 files <http://www.h5py.org/>`_  that contain tables
+that include mass, ionization, levels and lines data. The atom data that ships with TARDIS is located in data/atom.
 
 The dataset ``basic_atom_set`` contains the Atomic Number, Symbol of the elements and average mass of the elements.
 
@@ -125,8 +125,12 @@ There are two datasets for using the macro atom and branching line interactions.
 
 
 The ``macro_atom_data`` contains blocks of transition probabilities, several indices and flags. The Transition Type flag
-has three states -1 for downwards emitting, 0 for downwards internal and 1 for upwards internal (for more explanations please
-refer to :ref:`macroatom`)
+has three states:
+
+* -1 for downwards emitting
+* 0 for downwards internal
+* 1 for upwards internal (for more explanations, please
+refer to :ref:`macroatom`).
 
 Macro Atom Data
 ^^^^^^^^^^^^^^^
@@ -151,7 +155,7 @@ Macro Atom Data
 Here's the structure of the probability block. The atomic number, ion number and source level number are the same
 within each block, the destination level number the transition type and transition probability are changing.
 The transition probabilities are only part of the final probability and will be changed during the calculation.
-For details on the macro atom please refer to :ref:`macroatom`.
+For details on the macro atom, please refer to :ref:`macroatom`.
 
 +-------------+------------+-------------------+------------------------+-----------------+--------------------------+--------------------+
 |Atomic Number|Ion Number  |Source Level Number|Destination Level Number| Transition Type |Transition probabilities  |Transition Line ID  |
@@ -216,8 +220,8 @@ Indexing fun
 ------------
 
 The main problem with the atomic data is indexing. Most of these references require multiple numbers, e.g. atomic number,
-ion number and level number. The :py:module:`pandas`-framework provides the ideal functions to accomplish this. In TARDIS we extensively
-use :py:class:`pandas.MultiIndex`, :py:class:`pandas.Series` and :py:class:`pandas.DataFrame`
+ion number and level number. The `pandas <https://pandas.pydata.org/>`_ framework provides the ideal functions to accomplish this. In TARDIS, we extensively
+use :py:class:`pandas.MultiIndex`, :py:class:`pandas.Series` and :py:class:`pandas.DataFrame`.
 
 TO BE BETTER DOCUMENTED ...
 

docs/configuration/config_validator.rst

@@ -2,34 +2,36 @@
 Configuration Validator
 ***********************
 
-The default config validator takes a user configuration and a default configuration and creates a consistent and valid configuration for tardis based on the constraints given in the default configuration.  Both input data are normally given as a yaml dictionary with a consistent hierarchical structure i.e. for every item in the user configuration there has to be a declaration in the default configuration  at the same hierarchical level. This declaration can be either an unspecific empty level declaration like:
+The default config validator takes a user configuration and a default configuration and creates a consistent and valid configuration for TARDIS based on the constraints given in the default configuration. Both input data are normally given as a YAML dictionary with a consistent hierarchical structure, i.e. for every item in the user configuration there has to be a declaration in the default configuration at the same hierarchical level. This declaration can be either an unspecific empty level declaration like:
 - Main_level:
 	- Second_level:
 		- Third_level:
 			…
-or a declaration of  a configuration item like:
+or a declaration of a configuration item like:
 - item:
         - property_type: int
         - default: 1
         - mandatory: True
         - help:  ‘This is a doc string.'
 
-This contains always  the keywords help, default, mandatory, and property_type. The keyword help is  a doc-string which describes the corresponding item. Default specifies the default value which is used in case that no value for this item is specified in the corresponding user configuration item.  If the keyword mandatory is True, the item has to be specified in the user configuration.  The keyword property_type is used to specify the type of the item. At the moment, the config parser knows the following types:
-Int: The property type int is for integer like config items.
-Float: The property type float is for float like config items.
-String: The property type string is for string like config items.
-Quantity: The property type quantity is for physical quantities with units given as string. The string contains value and unit separated by a whitespace E.g. 2 cm.
-Range: The property type range specifies a range via start and end. Note: abs(start - end ) > 0
-Quantity_range: Like property type range but with quantities as start and stop. The consistency of the units is checked.
-Additionally to the four standard keywords the types integer, float, and quantity can have the keywords allowed_value and allowed_type. allowed_value specifies the allowed values in a list, whereas allowed_type specifies a range of allowed values like “x>10”.
+This contains always  the keywords ``help``, ``default``, ``mandatory``, and ``property_type``. The keyword help is  a doc-string which describes the corresponding item. "Default" specifies the default value which is used in case that no value for this item is specified in the corresponding user configuration item. If the keyword mandatory is ``True``, the item has to be specified in the user configuration. The keyword ``property_type`` is used to specify the type of the item. At the moment, the config parser knows the following types:
+- Int: The property type int is for integer like config items.
+- Float: The property type float is for float like config items.
+- String: The property type string is for string like config items.
+- Quantity: The property type quantity is for physical quantities with units given as string. The string contains value and unit separated by a whitespace E.g. 2 cm.
+- Range: The property type range specifies a range via start and end. Note: ``abs(start - end ) > 0``.
+- Quantity_range: Like property type range but with quantities as start and stop. The consistency of the units is checked.
+
+
+Additionally to the four standard keywords the types integer, float, and quantity can have the keywords ``allowed_value`` and ``allowed_type``. ``allowed_value`` specifies the allowed values in a list, whereas ``allowed_type`` specifies a range of allowed values, such as “x>10”.
 
 Container
 ^^^^^^^^^
 
-For more complex configurations with dependencies, you can use the containers which allow branching in the configuration. A container is declared in the default configuration file by setting the  property_type to container property and specifying the properties of the container with keyword type. The property_type of this section is container-declaration which allows you to specify the possible container items with the keyword container. For every specified container item, the code expects the declaration of all sub items. The keywords for this are “_“ + “name of the container item”.
-If the type declaration for this container is finished you can specify all container items like normal items. Here is an example for a container configuration with two branches
+For more complex configurations with dependencies, you can use the containers that allow branching in the configuration. A container is declared in the default configuration file by setting the  ``property_type`` to container property and specifying the properties of the container with keyword type. The ``property_type`` of this section is container-declaration that allows you to specify the possible container items with the keyword container. For every specified container item, the code expects the declaration of all sub items. The keywords for this are “_“ + “name of the container item”.
+If the type declaration for this container is finished, you can specify all container items like normal items. Here is an example for a container configuration with two branches:
 
-..source: yaml
+.. source: yaml
 - container_example:
         - property_type: container-property
         - type:
@@ -66,11 +68,12 @@ If the type declaration for this container is finished you can specify all conta
 How to use
 ^^^^^^^^^^
 
-To use the default parser create a new config object form the class ConfigurationValidator by either from a dictionaries or from yaml files::
+To use the default parser create a new config object form the class ConfigurationValidator either from a dictionaries or from YAML files::
 
-    My_config = ConfigurationValidator(default configuration dictionary, user configuration dictionary)
+- My_config = ConfigurationValidator(default configuration dictionary, user configuration dictionary)
 
 or
-- My_config = ConfigurationValidator.from_yaml(default configuration file, user configuration file)
-To access the configuration for tardis use the method get_config 
+- My_config = ConfigurationValidator.from_yaml (default configuration file, user configuration file).
+
+To access the configuration for TARDIS, use the method ``get_config``.
 

docs/configuration/configuration.rst

@@ -11,17 +11,16 @@ configuration file (with a small subset of the options that can be specified) ca
 
 .. warning::
     One should note that currently floats in YAML need to be specified in a special format:
-    any pure floats need to have a +/- after the e e.g. 2e+5
+    any pure floats need to have a +/- after the "e", e.g. 2e+5
 
 
 The TARDIS configuration consists of multiple sections that pertain to certain parts of the code. We will use the
-schemas to show what options are available. Our schema mark-up defines names in bold-fat as required.
-can be seen here:
+schemas to show what options are available. Our schema mark-up defines names in bold-fat as required and can be seen here:
 
 .. note::
 
     The following shows all the options (and their default settings) that are available for TARDIS. No other options
-    are allowed or available
+    are allowed or available.
 
 
 .. contents:: Overview
@@ -46,12 +45,12 @@ Model
 -----
 
 The next sections, describing the model, are very hierarchical. The base level is ``model`` and contains two subsections:
-``structure`` and ``abundances``. Both sections can either contain a ``file`` subsection which specifies a file and
+``structure`` and ``abundances``. Both sections can either contain a ``file`` subsection that specifies a file and
 file type where the information is stored or a number of other sections.
 
 .. jsonschema:: schemas/model.yml
 
-All types of ``structure`` definitions have two keywords in common ``v_inner_boundary`` and ``v_outer_boundary``.
+All types of ``structure`` definitions have two keywords in common: ``v_inner_boundary`` and ``v_outer_boundary``.
 In the ``structure`` section, one can specify a ``file`` section containing a ``type`` parameter
 (currently only ``artis`` is supported``) and a ``name`` parameter giving a path top a file.
 
@@ -60,7 +59,7 @@ parameter ``no_of_shells``. ``no_of_shells`` is the requested number of shells f
 requires a ``type``. Currently, only ``linear`` is supported.
 
 In the ``densities`` section the ``type`` parameter again decides on the parameters. The type ``uniform`` only needs a
- ``value`` parameter with a density compatible quantity. The type ``branch85_w7`` uses a seven order polynomial fit to
+ ``value`` parameter with a density compatible quantity. The type ``branch85_w7`` uses a seven-order polynomial fit to
  the W7 model and is parametrised by time since explosion. The parameters ``time_0`` and ``density_coefficient`` are set
  to sensible defaults and should not be changed.
 
@@ -69,10 +68,10 @@ and a ``name`` parameter giving a path to a file containing the abundance inform
 
 .. warning::
     In contrast to the ``structure`` section, the ``abundance`` section will not ignore abundances set in the rest of
-    the section, but merely will overwrite the abundances given in the file section.
+    the section but merely will overwrite the abundances given in the file section.
 
 The rest of the section can be used to configure uniform abundances for all shells, by giving the atom name and a
-relative abundance fraction. If it does not add up to 1., TARDIS will warn - but normalize the numbers.
+relative abundance fraction. If it does not add up to 1., TARDIS will warn --- but normalize the numbers.
 
 
 
@@ -81,23 +80,29 @@ Plasma
 
 .. jsonschema:: schemas/plasma.yml
 
-``inital_t_inner`` is initial temperature (will be updated for most modes of TARDIS - see convergence section) of the black-body on the inner
+``inital_t_inner`` is initial temperature (will be updated for most modes of TARDIS --- see convergence section) of the black-body on the inner
 boundary. ``initial_t_rad`` is the initial radiation temperature (will be updated for most modes of TARDIS - see convergence section). For debugging purposes and to compare to
 :term:`synapps` calculations one can disable the electron scattering. TARDIS will issue a warning that this is not physical.
-There are currently two ``plasma_type`` options available: ``nebular`` and ``lte`` which tell TARDIS how to run the
+There are currently two ``plasma_type`` options available: ``nebular`` and ``lte``, which tell TARDIS how to run the
 ionization equilibrium and level population calculations (see :ref:`plasmas` for more information).
 The radiative rates describe how to calculate the :math:`J_\textrm{blue}` needed for the :ref:`nlte` calculations and
-:ref:`macroatom` calculations. There are three options for ``radiative_rates_type``: 1) ``lte`` in which
-:math:`J_\textrm{blue} = \textrm{Blackbody}(T_\textrm{rad})`, 2) ``nebular`` in which
-:math:`J_\textrm{blue} = W \times \textrm{Blackbody}(T_\textrm{rad})`, 3) ``detailed`` in which the :math:`J_\textrm{blue}`
+:ref:`macroatom` calculations. There are three options for ``radiative_rates_type``: 
+
+1) ``lte``, in which
+:math:`J_\textrm{blue} = \textrm{Blackbody}(T_\textrm{rad})`
+
+2) ``nebular`` in which
+:math:`J_\textrm{blue} = W \times \textrm{Blackbody}(T_\textrm{rad})`
+
+3) ``detailed`` in which the :math:`J_\textrm{blue}`
 are calculated using an estimator (this is described in ??????).
 
-TARDIS currently supports three different kinds of line interaction: ``scatter`` - a resonance scattering implementation,
-``macroatom`` - the most complex form of line interaction described in :ref:`macroatom` and ``downbranch`` a simplified
+TARDIS currently supports three different kinds of line interaction: ``scatter`` --- a resonance scattering implementation,
+``macroatom`` --- the most complex form of line interaction described in :ref:`macroatom` and ``downbranch`` a simplified
 version of ``macroatom`` in which only downward transitions are allowed.
 
 Finally, ``w_epsilon`` describes the dilution factor to use to calculate :math:`J_\textrm{blue}` that are 0, which
-causes problem with the code (so :math:`J_\textrm{blue}` are set to a very small number).
+causes problemsl with the code (so :math:`J_\textrm{blue}` are set to a very small number).
 
 NLTE
 ^^^^
@@ -108,8 +113,8 @@ NLTE
         coronal_approximation: True
         classical_nebular: False
 
-The NLTE configuration currently allows setting ``coronal_approximation`` which sets all :math:`J_\textrm{blue}` to 0.
-This is useful for debugging with :term:`chianti` for example. Furthermore one can enable 'classical_nebular' to set all
+The NLTE configuration currently allows setting ``coronal_approximation``, which sets all :math:`J_\textrm{blue}` to 0.
+This is useful for debugging with :term:`chianti` for example. Furthermore, one can enable 'classical_nebular' to set all
 :math:`\beta_\textrm{Sobolev}` to 1. Both options are used for checking with other codes and should not be enabled in
 normal operations.
 
@@ -128,14 +133,14 @@ The ``no_of_packets`` parameter can take a float number for input convenience an
 used in each Monte Carlo loop. The parameters ``last_no_of_packets`` and ``no_of_virtual_packets`` influence the last run
 of the Monte Carlo loop (which calculates the final spectrum!) when the radiation field should have converged. ``last_no_of_packets`` is normally higher than
 ``no_of_packets`` to create a less noisy output spectrum. ``no_of_virtual_packets`` can also be set to greater than 0 (a useful number is 3) to
-use the Virtual Packet formalism. Increasing this number drasitcally increases computational costs(and memory requirements if they are logged)
+use the Virtual Packet formalism. Increasing this number drastically increases computational costs (and memory requirements if they are logged).
 The ``iterations`` parameter describes the maximum number of Monte Carlo loops executed in a simulation before it ends. Convergence criteria can be used to make the simulation stop
 sooner when the convergence threshold has been reached.
 
 The ``convergence_criteria`` section again has a ``type`` keyword. Currently, one type is allowed: ``damped``.
 All convergence criteria can be specified separately for the three variables for which convergence can be checked
-(``t_inner``, ``t_rad``, ``ws``) by specifying subsections in the ``convergence_criteria`` of the same name. These
-override then the defaults.
+(``t_inner``, ``t_rad``, ``ws``) by specifying subsections in the ``convergence_criteria`` of the same name. These then
+override the defaults.
 
 
 #. ``damped`` only has one parameter ``damping-constant`` and does not check for convergence. This can be used to fix the
@@ -148,7 +153,7 @@ Spectrum
 
 .. jsonschema:: schemas/spectrum.yml
 
-Start and end are given as Quantities with units. If they are given in
+``Start`` and ``end`` are given as Quantities with units. If they are given in
 frequency space they are switched around if necessary. The number of bins is
 just an integer. Finally, the method option selects the final spectral synthesis mode. Currently, there are three options:
 

docs/configuration/read_configuration.ipynb

@@ -25,7 +25,7 @@
    "cell_type": "markdown",
    "metadata": {},
    "source": [
-    "The configuration can be read this way. It will be validated by the json-schema schemas (including filling out default configuration options that had not been specified)"
+    "The configuration can be read this way. It will be validated by the json-schema schemas (including filling out default configuration options that had not been specified)."
    ]
   },
   {
@@ -46,7 +46,7 @@
    "cell_type": "markdown",
    "metadata": {},
    "source": [
-    "Despite the very simple nature of tardis_example.yml the output does contain all the default values"
+    "Despite the very simple nature of tardis_example.yml, the output does contain all the default values"
    ]
   },
   {