diff --git a/docs/atomic/atomic_data_description.rst b/docs/atomic/atomic_data_description.rst
index 8fc2e898c76..33ed6dc9680 100644
--- a/docs/atomic/atomic_data_description.rst
+++ b/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 `_. 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 `_. 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 (``_). 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 `_ 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 `_ 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 `_ 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 ...
diff --git a/docs/configuration/config_validator.rst b/docs/configuration/config_validator.rst
index c3de69caf46..ba19e94ec18 100644
--- a/docs/configuration/config_validator.rst
+++ b/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``.
diff --git a/docs/configuration/configuration.rst b/docs/configuration/configuration.rst
index b6d1b07e7fd..688d5df2e88 100644
--- a/docs/configuration/configuration.rst
+++ b/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:
diff --git a/docs/configuration/read_configuration.ipynb b/docs/configuration/read_configuration.ipynb
index e664998a6b0..38d2d93fd6e 100644
--- a/docs/configuration/read_configuration.ipynb
+++ b/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"
]
},
{
diff --git a/docs/credits.rst b/docs/credits.rst
index afb3b1d732b..02a4caddea4 100644
--- a/docs/credits.rst
+++ b/docs/credits.rst
@@ -12,7 +12,7 @@ Publication Policies
If you use this code for any publications or presentations please acknowledge
it. Please cite `Kerzendorf & Sim 2014
-`_ in the text
+`_ in the text.
Please add this paragraph to the Acknowledgement:
@@ -29,7 +29,7 @@ Please add this paragraph to the Acknowledgement:
If you use any of the full relativity treatments or use TARDIS for
-modelling Type II supernovae you also add this citation to acknowledgement
+modelling Type II supernovae, you also add this citation to acknowledgement
`Spectral modeling of type II supernovae. I. Dilution factors
`_:
@@ -37,7 +37,7 @@ modelling Type II supernovae you also add this citation to acknowledgement
\citep{2019A&A...621A..29V}
-The following bibtex entries are needed for the references.
+The following BibTeX entries are needed for the references.
.. code-block:: none
diff --git a/docs/development/continuous_integration.rst b/docs/development/continuous_integration.rst
index cf99d13d9a1..e5ac81191e2 100644
--- a/docs/development/continuous_integration.rst
+++ b/docs/development/continuous_integration.rst
@@ -3,14 +3,14 @@ Continuous Integration
**********************
We use a so-called `Continuous Integration`_ workflow with TARDIS.
-This means that each time a change is proposed (via pull-request)
-or a proposed change is merged into the main master branch a service will download the version
+This means that each time a change is proposed (via pull request)
+or a proposed change is merged into the main master branch, a service will download the version
and execute all the unit tests and integration tests offered with TARDIS. This helps
us detect bugs immediately.
The following pages explain how we setup automated debugging on TARDIS through a remote
cloud service, called Azure, hosted by Visual Studio Team Services. This is done by
-testing, building, and securely deploying this documentation to gh-pages. As
+testing, building, and securely deploying this documentation to `gh-pages`. As
a developer, one should be familiar with how to smoothly run tests and record the
documentation.
@@ -22,28 +22,28 @@ Testing
-------
To test TARDIS, we activate the designated environment, fetch the most recent reference data, install
-TARDIS, and use the python app tester, pytest::
+TARDIS, and use the Python app tester, `pytest`::
$ sh ci-helpers/fetch_reference_data.sh
$ source activate tardis
$ python setup.py build_ext --inplace
$ pytest tardis --tardis-refdata=$(ref.data.home) --test-run-title="TARDIS test" --cov=tardis --cov-report=xml --cov-report=html
-The build_ext command is for accomdating C/C++ extentions. The --inplace command is to ensure that the build is in the source directory.
+The build_ext command is for accommodating C/C++ extensions. The ``--inplace`` command is to ensure that the build is in the source directory.
-See https://docs.pytest.org/en/latest/ for more information on pytest.
+See https://docs.pytest.org/en/latest/ for more information on `pytest`.
Documentation
-------------
The documentation is built using Sphinx from the master branch. We use Restructured Text (reST) to encode the
required files, which are then converted into html links, that are then pushed to the root of the
-gh-pages branch.
+`gh-pages` branch.
See https://pythonhosted.org/an_example_pypi_project/sphinx.html and https://help.github.com/en/categories/github-pages-basics
for more information.
-Setting up a secure pathway to github
+Setting up a secure pathway to GitHub
=====================================
.. _install-ssh-key:
@@ -75,12 +75,12 @@ For explicit details, see `git deploy key`_.
Adding your key locally and copying the known host name
-------------------------------------------------------
-**Instead of the method recommended by azure, you can add all the github hosts by copying this output, starting from: github.com ssh-rs...**
+**Instead of the method recommended by azure, you can add all the GitHub hosts by copying this output, starting from: github.com ssh-rs...**
[Default option suggested by wk]::
ssh-keyscan -t rsa github.com
-If you wish to deploy the documentation locally to gh-pages, you must add the generated key on your computer and clone your repository::
+If you wish to deploy the documentation locally to `gh-pages`, you must add the generated key on your computer and clone your repository::
$ eval "$(ssh-agent -s)"
$ ssh-add ~/.ssh/id_rsa (Or whatever you called your key)
@@ -88,7 +88,7 @@ If you wish to deploy the documentation locally to gh-pages, you must add the ge
$ git clone git@github.com:myOrganizationName/myRepositoryName.git
-Accept the warning to add github and copy the saved known host, as we will need it for installing the key on Azure.
+Accept the warning to add GitHub and copy the saved known host, as we will need it for installing the key on Azure.
It should look something like (should look something like [1]As3...=ssh-rsa ..) and will be the last line added to::
~/.ssh/known_hosts
@@ -123,7 +123,7 @@ After which, one must use the InstallSSHKey@0 `Azure task`_ to add the ssh key.
Setting up the YAML file to deploy
----------------------------------
-YAML is short for "YAML Ain't Markup Language", as it is intented to be a simple way to write script
+YAML is short for "YAML Ain't Markup Language", as it is intended to be a simple way to write script
that is standard for all programing languages. It is the file that communicates directly with the
pipeline.
@@ -166,7 +166,7 @@ To download and add the ssh-key, prepare the scripts as::
inputs:
secureFile: 'id_azure_rsa'
-Secure files stored in the Azure server are encryped and again decrypted by the Azure task that uses the file.
+Secure files stored in the Azure server are encrypted and again decrypted by the Azure task that uses the file.
Download a secure file to a temporary location in the virtual machine::
@@ -203,20 +203,24 @@ After defining the variable, one could optionally encrypt it using this lock sym
Variables are referenced as $(variable_name), as seen in the InstallSSHKey@0 task in the hostName and sshPublicKey inputs.
Azure provides a list of agent hosts that can run the pipeline on a virtual machine. In our pipelines, we
+<<<<<<< HEAD
use the vm_Images: Ubuntu 16.04 and macOs-10.14.
+=======
+use the vm_Images: Ubuntu 16.04 and macOS-10.13.
+>>>>>>> Add periods, correct capitalizations, correct typos, and shuffle commas in continuous integration page.
In a job, you can list a single vm as::
pool:
vmImage: "Ubuntu 16.04"
-If you are using a self hosted agent (see `Installing and running a self hosted agent` for more details)::
+If you are using a self-hosted agent (see `Installing and running a self-hosted agent` for more details)::
pool:
name: "agent_pool_name"
-Or if you prefer to use multiple virtual machines and specity the maximum that can run at the same time, in
-addition to specifying variables as key value pairs such as conda and miniconda.url below ::
+Or if you prefer to use multiple virtual machines and specify the maximum that can run at the same time, in
+addition to specifying variables as key-value pairs such as conda and miniconda.url below. ::
strategy:
matrix:
@@ -230,22 +234,22 @@ addition to specifying variables as key value pairs such as conda and miniconda.
pool:
vmImage: $(imageName)
-This trick is also convenient for specying different variable builds for the same vmImage. As one can keep the vm_Image
-constant, and change the key value pair for each job in the matrix.
+This trick is also convenient for specifying different variable builds for the same vmImage. As one can keep the vm_Image
+constant and change the key value pair for each job in the matrix.
-Installing and running a self hosted agent
+Installing and running a self-hosted agent
------------------------------------------
-Microsoft supplies multiple hosted agents for running virtual machines, but it is useful to create a self hosted
-agent for incremental builds and the dependancy on local environments.
+Microsoft supplies multiple hosted agents for running virtual machines, but it is useful to create a self-hosted
+agent for incremental builds and the dependency on local environments.
-To add a new agent or agent pool, you must have administrator priveledges. See `agent pool security roles`_ to add a new administrator to an agent pool or for all the agent pools.
+To add a new agent or agent pool, you must have administrator privileges. See `agent pool security roles`_ to add a new administrator to an agent pool or for all the agent pools.
You can view your current lists of agents for each agent pool from: https://dev.azure.com/{your_organization}/_settings/agentpools.
-First decide if you will add your agent to an already exiting agent pool, or if you wish to add a new pool, by clicking on Add pool.
-If you choose to add a new pool, make sure to click on securtiy and add permissions to your team/self (you cannot directly add your own account), as well as granting access permission to all pipelines, or a specific pipeline.
-The first pool "Default" is owned by azure pipelines, and you cannot add pools to it without having even further permissions.
+First decide if you will add your agent to an already-existing agent pool, or if you wish to add a new pool, by clicking on Add pool.
+If you choose to add a new pool, make sure to click on security and add permissions to your team/self (you cannot directly add your own account), as well as granting access permission to all pipelines, or a specific pipeline.
+The first pool "Default" is owned by Azure Pipelines, and you cannot add pools to it without having even further permissions.
To give someone all security privileges:
- Go to http://dev.azure.com/{your_organization}/_settings/permissions
@@ -289,9 +293,9 @@ To uninstall ::
~/myagent$ sudo ./svc uninstall
For adding environmental variables or editing the `service file`_,
-see `self agent services`_
+see `self agent services`_.
-For more details, see `Azure self hosted agents`_
+For more details, see `Azure self hosted agents`_.
Carsus
------
diff --git a/docs/development/developer_faq.rst b/docs/development/developer_faq.rst
index fc1e373c425..58f25506632 100644
--- a/docs/development/developer_faq.rst
+++ b/docs/development/developer_faq.rst
@@ -3,5 +3,5 @@ Developer FAQ
*************
-Constants in TARDIS are all taken from astropy. The module tardis.constants import all constants currently
-from astropy.constants.astropy13constants
+Constants in TARDIS are all taken from Astropy. The module tardis.constants import all constants currently
+from astropy.constants.astropy13constants.
diff --git a/docs/development/git_workflow.rst b/docs/development/git_workflow.rst
index 95c4d66b1dc..2c7abb5d66a 100644
--- a/docs/development/git_workflow.rst
+++ b/docs/development/git_workflow.rst
@@ -3,33 +3,33 @@
General Workflow to add a new feature
=====================================
-In TARDIS we aim to stick to a test driven development. This uses the testing
-framework extensively starting with a test that shows this feature lacking via
+In TARDIS, we aim to stick to a test driven development. This uses the testing
+framework extensively, starting with a test that shows this feature lacking via
the implementation of the feature until the merging of the code to the main
repository.
-In most cases we try to break down big features into small, quantifiable goals
+In most cases, we try to break down big features into small, quantifiable goals
which are then acted upon.
* Document feature to be added in an issue and maybe ask the mailing
- list if this feature exists
+ list if this feature exists.
* Write a test that demonstrates what feature will be added.
* Run the test to verify that it fails in the way you think it should.
* If it fails in an unexpected way, your test may be wrong. This is a
- great time to ask the group for guidance
+ great time to ask the group for guidance.
* If it passes, you are done! You just added test coverage to an
already existing feature, and that is great! (unlikely)
* Add the feature (also known as "a simple matter of programming").
* Run the test to verify that it passes.
* Write documentation about your feature.
-* close issue/partial PR and add to changelog.
+* Close issue/partial PR and add to changelog.
Preparation and Working with Git
================================
-In this document, we refer to the Tardis ``master`` branch as the *trunk*. The first step is to setup up a python environment. We recommend to use
-Anaconda for this purpose and refer to our :doc:`Installation guide <../installation>` which covers this topic.
+In this document, we refer to the TARDIS ``master`` branch as the *trunk*. The first step is to setup up a python environment. We recommend using
+Anaconda for this purpose; refer to our :doc:`Installation guide <../installation>` which covers this topic.
.. _forking:
@@ -54,7 +54,7 @@ the `Generating SSH keys
Create your own fork of a repository
------------------------------------
-The following example shows how to fork the core ``astropy`` repository, but
+The following example shows how to fork the core ``Astropy`` repository, but
the same applies to other packages:
#. Log into your GitHub_ account.
@@ -103,13 +103,13 @@ In detail
* master
remotes/origin/master
- This tells you that you are currently on the ``master`` branch, and
+ This tells you that you are currently on the ``master`` branch and
that you also have a ``remote`` connection to ``origin/master``.
What remote repository is ``remote/origin``? Try ``git remote -v`` to
see the URLs for the remote connections. They will point to your GitHub
fork.
- Now connect to the TARDIS repository, so you can merge in changes from the
+ Now connect to the TARDIS repository so you can merge in changes from the
trunk::
cd
@@ -119,7 +119,7 @@ In detail
TARDIS_ repository.
Note that we've used ``git://`` for the URL rather than ``git@``. The
- ``git://`` URL is read only. This means that we can't accidentally (or
+ ``git://`` URL is read-only. This means that we can't accidentally (or
deliberately) write to the upstream repo, and we are only going to use it
to merge into our own code.
@@ -138,7 +138,7 @@ Installing TARDIS in develop mode
---------------------------------
TARDIS is designed so that it can generally be used directly out of the source
-tree by using ``import `` when running Python in the source of an
+tree by using ``import`` when running Python in the source of an
TARDIS repository clone.
#. Install TARDIS_ in develop mode::
@@ -182,7 +182,7 @@ given in the following sections.
you have not accidentally caused regressions, and add new tests to ensure
your contribution behaves correctly (see :ref:`testing-guidelines`).
-* Issue a pull request on github!
+* Issue a pull request on GitHub!
* As the code is converging to a final state, ensure your
documentation follows the guidelines (see :ref:`documentation-guidelines`).
@@ -192,9 +192,9 @@ given in the following sections.
least suggest a brief (one or two sentence) description of your change so
that another developer can add it to the changelog.
-This way of working helps to keep work well organized, with readable history.
+This way of working helps to keep work well-organized, with readable history.
This in turn makes it easier for project maintainers (that might be you) to
-see what you've done, and why you did it.
+see what you've done and why you did it.
See `linux git workflow`_ and `ipython git workflow`_ for some explanation.
@@ -209,7 +209,7 @@ confusion about which branch you are on.
Updating the mirror of trunk
----------------------------
-From time to time you should fetch the upstream (trunk) changes from GitHub::
+From time to time, you should fetch the upstream (trunk) changes from GitHub::
git fetch upstream
@@ -231,7 +231,7 @@ Making a new branch for each set of related changes will make it easier for
someone reviewing your branch to see what you are doing.
Choose an informative name for the branch to remind yourself and the rest of
-us what the changes in the branch are for. For example ``add-ability-to-fly``,
+us what the changes in the branch are for. For example, ``add-ability-to-fly``,
or ``buxfix-for-issue-42``.
::
@@ -245,18 +245,18 @@ or ``buxfix-for-issue-42``.
Generally, you will want to keep your feature branches on your public GitHub_
fork. To do this, you `git push`_ this new branch up to your
-github repo. Generally (if you followed the instructions in these pages, and
+GitHub repo. Generally (if you followed the instructions in these pages, and
by default), git will have a link to your GitHub repo, called ``origin``. You
push up to your own repo on GitHub with::
git push origin my-new-feature
-In git >= 1.7 you can ensure that the link is correctly set by using the
+In git >= 1.7, you can ensure that the link is correctly set by using the
``--set-upstream`` option::
git push --set-upstream origin my-new-feature
-From now on git will know that ``my-new-feature`` is related to the
+From now on, git will know that ``my-new-feature`` is related to the
``my-new-feature`` branch in the GitHub repo.
.. _edit-flow:
@@ -283,7 +283,7 @@ In more detail
python setup.py test
- If you have sphinx installed, you can also check that the documentation
+ If you have `Sphinx `_ installed, you can also check that the documentation
builds and looks correct::
python setup.py build_sphinx
@@ -359,14 +359,14 @@ When you are ready to ask for someone to review your code and consider a merge:
.. _using-virtualenv:
-Making sure your Pull request stays up-to-date
+Making sure your Pull Request stays up-to-date
----------------------------------------------
More often then not it will take a few days until a Pull Request is
-merged as the community gives feedback and/or you add new fixes. During this
-time often other pull requests are merged and the master branch evolves further.
-To make sure that your changes are still working on the new master you want to
-*rebase* your branch ontop of the evolved master
+merged as the community gives feedback and/or you add new fixes. Often during this
+time, other pull requests are merged and the master branch evolves further.
+To make sure that your changes are still working on the new master, you want to
+*rebase* your branch on top of the evolved master.
Rebasing on trunk
@@ -374,8 +374,8 @@ Rebasing on trunk
Let's say you thought of some work you'd like to do. You
:ref:`update-mirror-trunk` and :ref:`make-feature-branch` called
-``cool-feature``. At this stage trunk is at some commit, let's call it E. Now
-you make some new commits on your ``cool-feature`` branch, let's call them A,
+``cool-feature``. At this stage trunk is at some commit, let's call it E. Now,
+you make some new commits on your ``cool-feature`` branch --- let's call them A,
B, C. Maybe your changes take a while, or you come back to them after a while.
In the meantime, trunk has progressed from commit E to commit (say) G::
@@ -430,7 +430,7 @@ If it doesn't look good you may need to have a look at
If you have made changes to files that have also changed in trunk, this may
generate merge conflicts that you need to resolve - see the `git rebase`_ man
page for some instructions at the end of the "Description" section. There is
-some related help on merging in the git user manual - see `resolving a
+some related help on merging in the git user manual --- see `resolving a
merge`_.
If your feature branch is already on GitHub and you rebase, you will have to
@@ -442,7 +442,7 @@ remote called ``origin``, you use this command to force-push::
Note that this will overwrite the branch on GitHub, i.e. this is one of the few
ways you can actually lose commits with git. Also note that it is never allowed
-to force push to the main astropy repo (typically called ``upstream``), because
+to force push to the main Astropy repo (typically called ``upstream``), because
this would re-write commit history and thus cause problems for all others.
.. _recovering-from-mess-up:
@@ -481,11 +481,10 @@ If you forgot to make a backup branch::
Reviewing and helping others with Pull Requests
-----------------------------------------------
-Github offers an extensive array of tools to comment on Pull Requests (line
-based, normal forum-like discussion, etc.). This system is described here in
+Github offers an extensive array of tools to comment on Pull Requests (line-based, normal forum-like discussion, etc.). This system is described here in
detail ``_.
-However sometimes, it is easier to just add a few changes yourself to quickly
+However, it is sometimes easier to just add a few changes yourself to quickly
show what you would suggest to be changed. So it is possible to make a
Pull Request on a Pull Request.
diff --git a/docs/development/index.rst b/docs/development/index.rst
index e4fe42e68e9..b55a2056f7f 100644
--- a/docs/development/index.rst
+++ b/docs/development/index.rst
@@ -5,7 +5,7 @@ Developer Workflow
If you want to contribute to the development of TARDIS, please read through
this page and follow the guidelines outlined here. Many of the Development
workflow is taken from `Astropy `_ and credit belongs
+/en/stable/development/workflow/development_workflow.html>`_, and credit belongs
to the Astropy team for designing it.
.. toctree::
diff --git a/docs/development/issues.rst b/docs/development/issues.rst
index 8690f448fa2..9431ce6bc9e 100644
--- a/docs/development/issues.rst
+++ b/docs/development/issues.rst
@@ -4,7 +4,7 @@ Reporting Issues
TARDIS is under constant development. Thus, chances are high that some things
do not operate as intended. If any bugs, inconsistencies or missing
-functionalities are found, file an issue on our official `github
+functionalities are found, file an issue on our official `GitHub
`_ page.
We encourage any interested user to actively contribute to the development of
diff --git a/docs/development/release_workflow.rst b/docs/development/release_workflow.rst
index 1bb7ee8ab91..99d21ab64cb 100644
--- a/docs/development/release_workflow.rst
+++ b/docs/development/release_workflow.rst
@@ -26,5 +26,5 @@ Doing the actual release
========================
This is best done in a clean environment (so a fresh checkout from the master).
-We again use the astropy instructions:
+We again use the Astropy instructions:
``_
diff --git a/docs/development/running_tests.rst b/docs/development/running_tests.rst
index 8680331da4b..77e48476c65 100644
--- a/docs/development/running_tests.rst
+++ b/docs/development/running_tests.rst
@@ -2,29 +2,29 @@
Running tests
*************
-There are two basic categories of tests unit tests in TARDIS 1) the unit
-tests 2) integration tests. Unit tests check the outputs of individual functions
+There are two basic categories of tests in TARDIS: 1) the unit
+tests, and 2) the integration tests. Unit tests check the outputs of individual functions,
while the integration tests check entire runs for different setups of TARDIS.
-The Unit tests run very quickly and thus are executed after every suggested change
-to TARDIS. The Integration tests are much more costly and thus are only executed
+The unit tests run very quickly and thus are executed after every suggested change
+to TARDIS. The integration tests are much more costly and thus are only executed
every few days on a dedicated server.
All of them are based on the excellent ``astropy-setup-helpers`` package and
-``pytest``.
+`pytest `_.
-Running the unit tests
+Running the Unit Tests
======================
-This is very straight forward to run on your own machine. For very simple unit
-tests you can run this with:
+This is very straightforward to run on your own machine. For very simple unit
+tests, you can run this with:
.. code-block:: shell
> python setup.py test
-Running the more advanced unit tests requires Tardis Reference data that can be
+Running the more advanced unit tests requires TARDIS Reference data that can be
downloaded
(`tardis_refdata `_).
@@ -35,14 +35,14 @@ downloaded
Generating Plasma Reference
===========================
-You can generate Plasma Reference by the following command
+You can generate Plasma Reference by the following command:
.. code-block:: shell
> pytest -rs tardis/plasma/tests/test_complete_plasmas.py
--tardis-refdata="/path/to/tardis-refdata/" --generate-reference
-Running the integration tests
+Running the Integration Tests
=============================
These tests require reference files against which the results of the various
@@ -50,17 +50,17 @@ tardis runs are tested. So you first need to either download the current
reference files (`here `_)
or generate new ones.
-Both of of these require a configuration file for the integration tests:
+Both of these require a configuration file for the integration tests:
.. literalinclude:: integration.yml
:language: yaml
Inside the atomic data directory there needs to be atomic data for each of
the setups that are provided in the ``test_integration`` folder.
-If no references are given the first step is to generate them.
+If no references are given, the first step is to generate them.
The ``--less-packets`` option is useful for debugging purposes and will just
use very few packets to generate the references and thus make the process much
-faster - THIS IS ONLY FOR DEBUGGING PURPOSES. The ``-s`` option ensures that
+faster --- THIS IS ONLY FOR DEBUGGING PURPOSES. The ``-s`` option ensures that
TARDIS prints out the progress:
.. code-block:: shell
@@ -68,7 +68,7 @@ TARDIS prints out the progress:
> python setup.py test --args="--integration=integration.yml -m integration
--generate-reference --less-packets"
-To run the test after having run the ``--generate-references`` all that is
+To run the test after having run the ``--generate-references``, all that is
needed is:
.. code-block:: shell
@@ -77,10 +77,10 @@ needed is:
--less-packets" --remote-data
-Setting up the Dokuwiki report
+Setting up the DokuWiki report
==============================
-A normal dokuwiki installation is performed on the required server. Before the
+A normal `DokuWiki `_ installation is performed on the required server. Before the
connection works one is requires to set the option remote access in the
settings. If this is not done the ``dokuwiki`` python plugin will not connect
with the warning ``DokuWikiError: syntax error: line 1, column 0``. One also
@@ -88,11 +88,11 @@ has to enable this for users (``remoteuser`` option) otherwise the error:
``ProtocolError for xmlrpc.php?p=xxxxxx&u=tardistester: 403 Forbidden``
will appear.
-Another important configuration option is to enable embedded html ``htmlok``
-otherwise it won't show nice html page reports.
+Another important configuration option is to enable embedded html ``htmlok``;
+otherwise, it won't show nice html page reports.
Finally, one has to call the `python setup.py test` with the ``--remote-data``
-option to allow posting to an external dokuwiki server.
+option to allow posting to an external DokuWiki server.
diff --git a/docs/development/update_refdata.rst b/docs/development/update_refdata.rst
index f7a77ad2537..3e8f59c213c 100644
--- a/docs/development/update_refdata.rst
+++ b/docs/development/update_refdata.rst
@@ -4,7 +4,7 @@ Procedure to update the reference data
We assume that you have added the necessary changes to TARDIS and have an open pull request.
-#. Fork the ``tardis-refdata`` repository like described in :ref:`development-workflow`.
+#. Fork the ``tardis-refdata`` repository as described in :ref:`development-workflow`.
#. Clone ``tardis-refdata`` to your computer. Then make a new branch named the same as your new TARDIS feature branch. Make sure to have correctly set up the ``upstream`` remote as explained in :ref:`reviewing-and-helping-with-pr`.
@@ -71,14 +71,14 @@ We assume that you have added the necessary changes to TARDIS and have an open p
#. Ensure TARDIS pull request passes Travis-CI again and ping someone to merge your PR to the TARDIS master branch.
-Congratulations! You have updated TARDIS to be better. Have a beer and steak (or Tofu if you are vegetarian/vegan)
+Congratulations! You have updated TARDIS to be better. Have a beer and steak (or Tofu if you are vegetarian/vegan).
Troubleshooting
###############
* Unable to generate reference data
- * If generating fails due to an inability to open ``chianti_He.h5``, make sure that you have activated your `tardis` conda environment, and ``git-lfs`` is installed. Fetch and pull the files from GitHub as explained in step 4.
+ * If generating fails due to an inability to open ``chianti_He.h5``, make sure that you have activated your `tardis` conda environment and that ``git-lfs`` is installed. Fetch and pull the files from GitHub as explained in step 4.
* Error when running ``comparer = ReferenceComparer(ref2_hash='upstream/pr/XX')`` on the comparer notebook: ``No such file or directory: '.../unit_test_data.h5'``
* If notebook file is unable to find the file ``unit_test_data.h5``, make sure you have correctly set your upstream as explained in :ref:`reviewing-and-helping-with-pr`.
diff --git a/docs/index.rst b/docs/index.rst
index d7646934154..3dceae076fb 100644
--- a/docs/index.rst
+++ b/docs/index.rst
@@ -9,7 +9,7 @@
..
##################################
-Tardis Core Package Documentation
+TARDIS Core Package Documentation
##################################
.. image:: graphics/tardis_banner.svg
@@ -22,11 +22,11 @@ including software engineers, computer scientists, statisticians,
and astrophysicists.
If you use this code for any publications or presentations please follow our
-citation guidelines in :ref:`tardiscredits`
+citation guidelines in :ref:`tardiscredits`.
User modifications and additions that lead to publications **need to be handed
back to the community** by incorporating them into TARDIS.
-Please contact the TARDIS team via the `github page
+Please contact the TARDIS team via the `GitHub page
`_ if you have questions or need
assistance.
@@ -57,7 +57,6 @@ assistance.
Physics overview
physics/plasma/index
- physics/montecarlo/index
.. toctree::
diff --git a/docs/installation.rst b/docs/installation.rst
index 408db1764e6..0ab170dbae9 100644
--- a/docs/installation.rst
+++ b/docs/installation.rst
@@ -8,7 +8,7 @@ Before installing TARDIS, please check its :ref:`requirements
`. We provide :ref:`instructions ` for installing TARDIS using
Anaconda. If you encounter problems, consult the
:ref:`troubleshooting ` section. Once you have
-installed TARDIS, check out :doc:`running` for instructions of how to perform
+installed TARDIS, check out :doc:`running` for instructions regarding how to perform
simple TARDIS calculations.
.. _requirements_label:
@@ -16,11 +16,11 @@ simple TARDIS calculations.
.. warning::
- TARDIS is only compatbile with Python >3.6
+ TARDIS is only compatible with Python >3.6
.. note::
- We strongly recommend to install TARDIS within an Anaconda environment and
- to always use the lastest github development version.
+ We strongly recommend installing TARDIS within an Anaconda environment and
+ to always use the latest GitHub development version.
Requirements
============
@@ -35,7 +35,7 @@ instructions to Astropy.
Installing TARDIS with Anaconda
===============================
-We highly recommend using the Anaconda python environment to install TARDIS (or
+We highly recommend using the `Anaconda `_ Python environment to install TARDIS (or
any other scientific packages for that matter). Anaconda has the advantage of
being an isolated environment that can be set to be the default one, but by no
means will mess with your other environments. It will also work on computers
@@ -43,7 +43,7 @@ where ``root``-rights are not available. Use these `instructions
`_ to install Anaconda on your
machine. The next step is to create an environment for TARDIS that contains all
of the necessary packages (this ensures that TARDIS requirements won't clash
-with any other python installs on disc::
+with any other Python installs on disc)::
First, download the `environment definition file `_ from::
@@ -92,7 +92,7 @@ Enabling parallel execution with OpenMP
Manually, cloning the repository enables other options such as running the code in parallel (enabling OpenMP).
-In general we encourage to download the compilers from `conda` as we then can ensure that they work with TARDIS.
+In general, we encourage downloading the compilers from `conda` as we then can ensure that they work with TARDIS.
Within the TARDIS conda environment do::
conda install -c conda-forge compilers
@@ -111,14 +111,15 @@ To compile TARDIS for parallel execution::
.. _troubleshooting_inst_label:
+
Installation Troubles (FAQ)
===========================
We highly encourage with any installation problems to try the recommended install
-method because this often fix problems. Here are some common problems when
+method because this often fixes problems. Here are some common problems when
installing and their fixes:
-**Problem:** While building tardis via ``python setup.py`` build you
+**Problem:** While building TARDIS via ``python setup.py`` build you
may encounter the following error::
error: tardis/montecarlo/montecarlo.c: Could not find C file tardis/montecarlo/montecarlo.c for Cython file tardis/montecarlo/montecarlo.pyx when building extension tardis.montecarlo.montecarlo. Cython must be installed to build from a git checkout.
@@ -126,7 +127,7 @@ may encounter the following error::
**Solution:** There are several solutions to this problem. A clean checkout will
help. To clean up your repository please try ``python setup.py clean`` and
-then ``git clean -dfx`` (**WARNING** will delete any non tardis file in that directory)
+then ``git clean -dfx`` (**WARNING** will delete any non-TARDIS file in that directory)
This will often clean this problem. If it still persists:
Go into the tardis/montecarlo directory and build montecarlo.c by hand::
@@ -147,7 +148,7 @@ from tardis/_compiler.c:1: /Users/yssavo/miniconda2/envs/tardis-show2/lib/gcc/x8
**Solution:** Install gcc8 from macports and then install with these flags: `link_args = ['-fopenmp','-Wl,-rpath,/opt/local/lib/gcc8/']`
-**Problem:** While building tardis(via python 2.7) via ``python setup.py`` build you
+**Problem:** While building TARDIS (via python 2.7) via ``python setup.py`` build you
may encounter the following error::
TypeError: super() argument 1 must be type, not None
@@ -156,7 +157,7 @@ may encounter the following error::
Command "python setup.py egg_info" failed with error code 1 in /tmp/pip-req-build-wPB39p/
-**Solution:** The cause for this problem is sphinx , or sphinx version . It can be easily solved by installing sphinx 1.5.6.
+**Solution:** The cause for this problem is Sphinx or Sphinx version. It can be easily solved by installing Sphinx 1.5.6.
The command for the same is :
pip install sphinx==1.5.6
diff --git a/docs/models/examples/Custom_Density_And_Boundary_Velocities.ipynb b/docs/models/examples/Custom_Density_And_Boundary_Velocities.ipynb
index 06804eac9d7..30adb1d86a9 100644
--- a/docs/models/examples/Custom_Density_And_Boundary_Velocities.ipynb
+++ b/docs/models/examples/Custom_Density_And_Boundary_Velocities.ipynb
@@ -48,7 +48,7 @@
"source": [
"* The first line specifies the time in days after the explosion\n",
"* After a skipped line, each row corresponds to a shell with index specified by the first column.\n",
- "* The second column lists the velocities of the outer boundary of the cell in km/s.\n",
+ "* The second column lists the velocities of the outer boundary of the cell in km / s.\n",
"* The third column lists the density of the cell.\n",
"\n",
"__IMPORTANT__\n",
@@ -81,7 +81,7 @@
"metadata": {},
"source": [
"* The first line indicates which elements (or isotopes) correspond to which columns.\n",
- "* After a skipped line, each row specifies the chemical abundance of one shell. Therefore the numbers in a given row should sum to 1.0\n",
+ "* After a skipped line, each row specifies the chemical abundance of one shell. Therefore the numbers in a given row should sum to 1.0.\n",
"\n",
"__IMPORTANT__\n",
"\n",
@@ -407,7 +407,7 @@
"source": [
"## Example 1) v_inner_boundary lower than first velocity in density file\n",
"\n",
- "In this example, the first velocity in the density file is 9500 km/s. The user can specify in the config file the velocity of the inner boundary to a lower velocity, say v_inner_boundary = 9000 km/s. This will cause TARDIS to raise an error."
+ "In this example, the first velocity in the density file is 9500 km/s. The user can specify in the config file the velocity of the inner boundary to be a lower velocity, say v_inner_boundary = 9000 km/s. This will cause TARDIS to raise an error."
]
},
{
diff --git a/docs/models/examples/abundancecust.rst b/docs/models/examples/abundancecust.rst
index 0cdfbb6a1e3..f756e9b2241 100644
--- a/docs/models/examples/abundancecust.rst
+++ b/docs/models/examples/abundancecust.rst
@@ -8,8 +8,8 @@ ASCII Format
=============
To use a stratified ejecta composition in TARDIS, the elemental abundances may
-be specified on a per-cell basis via an external ascii file (similar to setting
-up a :doc:`custom density ` profile). An ascii file that could
+be specified on a per-cell basis via an external ASCII file (similar to setting
+up a :doc:`custom density ` profile). An ASCII file that could
work on a mesh with ten cells should be formatted like this:
.. literalinclude:: abund.dat
@@ -21,10 +21,10 @@ In this file:
- the remaining 30 entries in each row give the set of elemental abundances for atomic number Z=1 to Z=30 (in order)
The abundances are specified as mass fractions (i.e. the sum of columns 1 to 30
-in each row should be 1.0). TARDIS does not currently include any elements
-heavier that Z=30. The mass fractions specified will be adopted directly in
-the TARDIS calculations - so if your model is e.g. based on an explosion
-simulation you may need to calculate the state of any radioactive decay chains
+in each row should be 1.0). TARDIS does not currently include any elements
+heavier that Z=30. The mass fractions specified will be adopted directly in
+the TARDIS calculations --- so if your model is, for example, based on an explosion
+simulation, you may need to calculate the state of any radioactive decay chains
at the correct epoch.
The example file shown here has three simple layers:
@@ -38,13 +38,13 @@ The example file shown here has three simple layers:
.. warning::
The example given here is to show the format only. It is not a
- realistic model. In any real calculation better resolution
+ realistic model. In any real calculation, better resolution
(i.e. more grid points) should be used.
.. warning::
The calculation can be no better / more complete than the atomic
- data set. For further information on the atomic database -
+ data set. For further information on the atomic database ---
including details of how to develop your own dataset to suit your
needs, please contact us.
@@ -53,7 +53,7 @@ TARDIS ascii input file
If you create a correctly formatted abundance profile file (called "abund.dat"
in this example), you can use it in TARDIS by putting the following lines in
-the model section of the yaml file:
+the model section of the YAML file:
.. literalinclude:: tardis_configv1_abundance_cust_example.yml
:language: yaml
@@ -63,7 +63,7 @@ CSV Format
==========
In this format, both elemental and isotopic abundances may
-be specified on a per-cell basis via an external csv file. A csv file that could
+be specified on a per-cell basis via an external CSV file. A CSV file that could
work on a mesh with ten cells should be formatted like this:
.. literalinclude:: tardis_model_abund.csv
@@ -76,7 +76,7 @@ work on a mesh with ten cells should be formatted like this:
.. danger::
The header line for the isotopic abundance structure can under no
- circumstances start with a '#'
+ circumstances start with a '#'.
In this file:
@@ -94,20 +94,20 @@ The example file shown here has three simple layers:
- a middle region that is composed of O and Mg
-- an outer region that is composed of C and O.
+- an outer region that is composed of C and O
.. note::
Suppose you specify Elemental and Isotopic abundances for the same element. For ex-
:code:`Ni` and :code:`Ni56`.
- Here, Ni will refer to the stable Nickel, i.e. (Z=26, A=58).
+ Here, Ni will refer to the stable Nickel (i.e. Z=26, A=58).
.. note::
As with the custom density file, the first row will be ignored. It is
supposed to give the composition below the photosphere. Thus, the first row
- (after the header) can be filled with dummy values
+ (after the header) can be filled with dummy values.
.. warning::
@@ -115,20 +115,20 @@ The example file shown here has three simple layers:
realistic model. In any real calculation better resolution
(i.e. more grid points) should be used.
-TARDIS csv input file
+TARDIS CSV input file
=====================
If you create a correctly formatted abundance profile file (called "tardis_model_abund.csv"
in this example), you can use it in TARDIS by putting the following lines in
-the model section of the yaml file:
+the model section of the YAML file:
.. literalinclude:: tardis_configv1_isotope_abundance_cust_example.yml
:language: yaml
-Convert ascii abundance file format to csv format
+Convert ASCII abundance file format to CSV format
=================================================
-If you want to convert an ASCII abundance file(say "abund.dat") to CSV format, you can use
+If you want to convert an ASCII abundance file (say "abund.dat") to CSV format, you can use
:code:`convert_abundances_format` function for it. Here is an example to demonstrate this:
.. code:: python
diff --git a/docs/models/examples/abundanceuni.rst b/docs/models/examples/abundanceuni.rst
index 07017fb9648..59986517b52 100644
--- a/docs/models/examples/abundanceuni.rst
+++ b/docs/models/examples/abundanceuni.rst
@@ -7,10 +7,10 @@ Overview
The simplest possibility for specifying an ejecta composition is to use a
uniform abundance pattern in all cells specified in the density profile setup
-step. These constant abundances can be supplied directly in the input (yaml)
+step. These constant abundances can be supplied directly in the input (YAML)
file. Elemental and Isotopic abundances are set in the "abundances" subsection of the "model"
section, following the "type: uniform" specifier (see example input
-file below). They are specified as mass fractions. E.g.
+file below). They are specified as mass fractions, e.g.
.. code-block:: none
@@ -18,18 +18,18 @@ file below). They are specified as mass fractions. E.g.
S: 0.2
Ni56: 0.2
-will set the mass fraction of silicon (Z=14) to 0.6, sulphur (Z=16) to 0.2 and Nickel(Z=26, A=56) to 0.2.
+will set the mass fraction of silicon (Z=14) to 0.6, sulphur (Z=16) to 0.2 and Nickel (Z=26, A=56) to 0.2.
.. note::
- Suppose you specify Elemental and Isotopic abundance for the same element. For ex-
+ Suppose you specify Elemental and Isotopic abundance for the same element, e.g.
.. code-block:: none
Ni: 0.8
Ni56: 0.2
- Here, Ni will refer to the stable Nickel, i.e. (Z=26, A=58).
+ Here, Ni will refer to the stable Nickel (i.e. Z=26, A=58).
.. note::
@@ -40,8 +40,8 @@ will set the mass fraction of silicon (Z=14) to 0.6, sulphur (Z=16) to 0.2 and N
TARDIS input file
=================
-The following example shows the relevant section of a TARDIS input yaml file
-which specifies a uniform ejecta composition;
+The following example shows the relevant section of a TARDIS input YAML file
+which specifies a uniform ejecta composition.
.. literalinclude:: tardis_configv1_abundance_uniform_example.yml
:language: yaml
diff --git a/docs/models/examples/densitycust.rst b/docs/models/examples/densitycust.rst
index 417e7de7c5c..3a49aa07c8e 100644
--- a/docs/models/examples/densitycust.rst
+++ b/docs/models/examples/densitycust.rst
@@ -7,10 +7,10 @@ Using a custom density profile
Overview
========
-TARDIS has also the capability to work with arbitrary density profiles. This is
+TARDIS also has the capability to work with arbitrary density profiles. This is
particularly useful if the results of detailed explosion simulations should be
mapped into TARDIS. The density profile is supplied in the form of a simple
-ascii file that should look something like this:
+ASCII file that should look something like this:
.. literalinclude:: density.dat
@@ -20,7 +20,7 @@ In this file:
- (the second line in our example is a comment)
-- the remaining lines (ten in our example) give an indexed table of points that specify mass density (g / cm^3) as a function of velocity (km /s).
+- the remaining lines (ten in our example) give an indexed table of points that specify mass density (g / cm^3) as a function of velocity (km / s).
TARDIS will use this table of density versus velocity to specify the density
distribution in the ejecta. For the calculation, TARDIS will use the reference
@@ -47,7 +47,7 @@ The values in the example here define a density profile that is dropping off wit
Inner Boundary
==============
-The first velocity-density pair in a custom density file (given by index 0) specifies the velocity of the inner boundary approximation. The density associated with this velocity is the density within the inner boundary, which does not affect TARDIS spectra. Therefore, the first density (5.4869692e-10 in the example above) can be replaced by a placeholder value. The user can choose to both specify a custom density file AND specify v_inner_boundary or v_outer_boundary in the configuration YAML file for a TARDIS run. However, the YAML specified values must be within the velocity range specified in the custom density file, otherwise TARDIS will raise an error. When one of the YAML specified boundary velocities falls within the velocity range specified in the custom density file, then the boundary velocity is set equal to the number in the configuration YAML file. This has the effect of splitting a cell in the custom density file into two parts, a region within the boundary and a region outside the boundary.
+The first velocity-density pair in a custom density file (given by index 0) specifies the velocity of the inner boundary approximation. The density associated with this velocity is the density within the inner boundary, which does not affect TARDIS spectra. Therefore, the first density (5.4869692e-10 in the example above) can be replaced by a placeholder value. The user can choose to both specify a custom density file AND specify v_inner_boundary or v_outer_boundary in the configuration YAML file for a TARDIS run. However, the YAML-specified values must be within the velocity range specified in the custom density file, otherwise TARDIS will raise an error. When one of the YAML-specified boundary velocities falls within the velocity range specified in the custom density file, then the boundary velocity is set equal to the number in the configuration YAML file. This has the effect of splitting a cell in the custom density file into two parts, a region within the boundary and a region outside the boundary.
.. toctree::
@@ -58,7 +58,7 @@ It is always a good idea to check the model velocities and abundances used in a
.. warning::
The example given here is to show the format only. It is not a
- realistic model. In any real calculation better resolution
+ realistic model. In any real calculation, better resolution
(i.e. more grid points) should be used.
@@ -67,7 +67,7 @@ TARDIS input file
If you create a correctly formatted density profile file (called "density.dat"
in this example), you can use it in TARDIS by putting the following lines in
-the model section of the yaml file:
+the model section of the YAML file:
.. literalinclude:: tardis_configv1_density_cust_example.yml
:language: yaml
diff --git a/docs/models/examples/densityexp.rst b/docs/models/examples/densityexp.rst
index 2b80f72f699..cc65dae4e05 100644
--- a/docs/models/examples/densityexp.rst
+++ b/docs/models/examples/densityexp.rst
@@ -13,19 +13,19 @@ explosion) is assumed to follow a functional form:
\rho (v, t_{exp}) = \rho_0 (t_{0} / t_{exp})^{3} \exp( -v / v_0)
defined by reference density, velocity and time parameters. These
-parameters are set in the input yaml file, specifically in the "structure"
+parameters are set in the input YAML file, specifically in the "structure"
subsection of the "model" section, under the "density" heading (see
example below).
.. note::
- In this mode, the velocity grid has to be explicitly defined in the yml file (see example below)
+ In this mode, the velocity grid has to be explicitly defined in the YAML file (see example below)
TARDIS input file example
=========================
-The following example shows the relevant sections of a TARDIS input yaml file,
+The following example shows the relevant sections of a TARDIS input YAML file,
specifying an exponential density:
.. literalinclude:: tardis_configv1_density_exponential_example.yml
diff --git a/docs/models/examples/densitypow.rst b/docs/models/examples/densitypow.rst
index 58512a79db2..13def79bf5b 100644
--- a/docs/models/examples/densitypow.rst
+++ b/docs/models/examples/densitypow.rst
@@ -19,13 +19,13 @@ example below).
.. note::
- In this mode, the velocity grid has to be explicitly defined in the yml file (see example below)
+ In this mode, the velocity grid has to be explicitly defined in the YAML file (see example below)
TARDIS input file example
=========================
-The following example shows the relevant sections of a TARDIS input yaml file,
+The following example shows the relevant sections of a TARDIS input YAML file,
specifying a power law density:
.. literalinclude:: tardis_configv1_density_power_law_example.yml
diff --git a/docs/models/examples/modelconfig.rst b/docs/models/examples/modelconfig.rst
index d838df5499b..c9ee0d99506 100644
--- a/docs/models/examples/modelconfig.rst
+++ b/docs/models/examples/modelconfig.rst
@@ -14,7 +14,7 @@ ejecta density and its composition have to be specified on a velocity grid.
Since homology is implicitly assumed, the velocity grid immediately translates into a radial mesh
-The density and composition may be specified independently in the following ways
+The density and composition may be specified independently in the following ways:
Specifying the density
======================
diff --git a/docs/models/index.rst b/docs/models/index.rst
index b0bb864dabb..56173328c24 100644
--- a/docs/models/index.rst
+++ b/docs/models/index.rst
@@ -4,24 +4,24 @@ Model
TARDIS requires a model of the homologously expanding ejecta in order to run a simulation.
A model will include information like the velocity shell structure, abundances, density, etc.
-TARDIS offers two ways of specifying the model: either directly in the configuration yaml file
+TARDIS offers two ways of specifying the model: either directly in the configuration YAML file
or separately in a model.csvy file. See `here `_ for an explanation of
-the csvy file format and :ref:`here <../running/configuration/config-file>` for a link to the csvy_model schema.
+the CSVY file format and :ref:`here <../running/configuration/config-file>` for a link to the csvy_model schema.
.. note::
- We highly recommend using the cleaner csvy format.
+ We highly recommend using the cleaner CSVY format.
CSVY Model
==========
-The TARDIS YAML delimiter for csvy files is ``---``. This means that each csvy model
+The TARDIS YAML delimiter for CSVY files is ``---``. This means that each CSVY model
file has the following structure: The first line of the file is the YAML delimiter,
-followed by the YAML portion of the csvy model. A line consisting of only the YAML
-delimiter separates the YAML portion of the csvy file from the csv part. The YAML part
-of the csvy file is for setting model parameters like **v_inner_boundary** or
-**model_density_time_0** while the csv part of the file is for setting profiles of
+followed by the YAML portion of the CSVY model. A line consisting of only the YAML
+delimiter separates the YAML portion of the CSVY file from the CSV part. The YAML part
+of the CSVY file is for setting model parameters like **v_inner_boundary** or
+**model_density_time_0**, while the CSV part of the file is for setting profiles of
physical parameters of the model (e.g. abundances, radiative temperature, dilution factor, etc).
-If you use the csvy model, then you will need to specify the path to the csvy model file
+If you use the CSVY model, then you will need to specify the path to the CSVY model file
in the main TARDIS configuration file:
.. code-block::
diff --git a/docs/physics/index.rst b/docs/physics/index.rst
index ce7f8b15dbe..532a3c4501c 100644
--- a/docs/physics/index.rst
+++ b/docs/physics/index.rst
@@ -4,13 +4,14 @@ Physics of TARDIS
.. warning::
- This section of the TARDIS documentation is still incomplete
+ This section of the TARDIS documentation is still `incomplete
+`_.
This part of the documentation is dedicated to providing some physical and
astrophysical background for TARDIS. If you do not find the information you are
looking for, consult the official TARDIS publications and the references therein.
-Eventually, information about the following topics will be provided
+Eventually, information about the following topics will be provided:
* Spectral Synthesis in SNe Ia ejecta
* Radiative Transfer Primer
diff --git a/docs/physics/montecarlo/discretization.rst b/docs/physics/montecarlo/discretization.rst
index 321d92b3404..baef5eeb2f0 100644
--- a/docs/physics/montecarlo/discretization.rst
+++ b/docs/physics/montecarlo/discretization.rst
@@ -1,6 +1,6 @@
-*******************************************
-Monte Carlo Discretization - Energy Packets
-*******************************************
+*********************************************
+Monte Carlo Discretization --- Energy Packets
+*********************************************
While it is instructive to think about tracking the propagation history of
photons when illustrating the basic idea behind Monte Carlo radiative transfer
@@ -12,19 +12,19 @@ building blocks of the Monte Carlo calculation. These basic Monte Carlo quanta
are commonly referred to as "energy packets" or simply "packets".
During a Monte Carlo calculation, a large number of packets, all with a certain
-energy :math:`\varepsilon` are created. In addition, each packet is associated
+energy :math:`\varepsilon`, are created. In addition, each packet is associated
with a frequency. These assignments are performed in a manner which ensures
that the ensemble of packets represents the spectral energy distribution of the
radiation field (see :doc:`Propagation `).
During the simulation, the energy of the packet remains constant in the local
co-moving frame (see :doc:`Reference Frames <../physics/referenceframes>` for
-details about the lab and co-moving frame). This naturally ensures energy
+details about the lab and co-moving frames). This naturally ensures energy
conservation and constitutes the main advantage of this discretization scheme.
There is one side effect of this so-called indivisible packet energy scheme
-which often causes confusion: even during radiation-matter interactions the
+which often causes confusion: Even during radiation-matter interactions the
packet energy is conserved in the co-moving frame (see :doc:`Propagation
-`). However the frequency associated with a packet may chance
+`). However, the frequency associated with a packet may change
(e.g. during non-resonant line interactions). As a consequence, packets may
represent a varying number of real photons during their lifetime.
diff --git a/docs/physics/montecarlo/estimators.rst b/docs/physics/montecarlo/estimators.rst
index c4ea19869e3..8c236e78651 100644
--- a/docs/physics/montecarlo/estimators.rst
+++ b/docs/physics/montecarlo/estimators.rst
@@ -6,15 +6,15 @@ An integral part of Monte Carlo radiative transfer calculations consists of
reconstructing macroscopic radiation field properties from the ensemble of
packet interaction histories. TARDIS uses volume-based Monte Carlo estimators
for this purpose. This concept was originally developed by :cite:`Lucy1999` and
-successively refined for example by :cite:`Lucy1999a`, :cite:`Lucy2002` and
+successively refined, for example, by :cite:`Lucy1999a`, :cite:`Lucy2002` and
:cite:`Lucy2003`.
Basic Principle
===============
The basic principle underlying volume-based estimators is best illustrated
-at the example of reconstructing the mean radiation field energy density within
-a certain control volume (in most cases this will be a grid cell). A simple
+by the example of reconstructing the mean radiation field energy density within
+a certain control volume (in most cases, this will be a grid cell). A simple
approach would involve explicitly counting the number of Monte Carlo packets
which reside in the control volume at a certain time. Although being intuitive,
this approach suffers heavily from Monte Carlo shot noise, in particular in
@@ -60,7 +60,7 @@ estimator derived above:
J = \frac{1}{4\pi \Delta V \Delta t}\sum_i \varepsilon_i l_i D_{\mu}
-An intensity weighted estimate for the mean frequency is obtained from
+An intensity-weighted estimate for the mean frequency is obtained from
.. math::
@@ -68,22 +68,22 @@ An intensity weighted estimate for the mean frequency is obtained from
.. note::
- Compared to the estimtors derived in the previous section, the ones
+ Compared to the estimators derived in the previous section, the ones
presented here involve a relativistic factor, :math:`D_{\mu} = (1 - \beta
\mu)`, which ensures the correct frame transformation behaviour of the
estimators (to first order in :math:`v/c`).
Using the estimators just derived the radiation temperature (which should be
-interpreted as a colour temperature) of the radiation field
+interpreted as a colour temperature) of the radiation field,
.. math::
T_{\mathrm{R}} = \frac{h}{k_{\mathrm{B}}} \frac{\pi^4}{360 \zeta(5)} \frac{\bar \nu}{J}
may be derived. The normalization constants, involving Riemann's zeta function,
-are a consequence from the definition of this colour temperature: this should
-be the temperature of a black body radiation field whose mean frequency is
+are a consequence from the definition of this colour temperature: This should
+be the temperature of a black-body radiation field whose mean frequency is
equal to the one reconstructed from the Monte Carlo simulation. With the
temperature determined, the dilution factor, describing the deviation of the
radiation field from a thermal field with the same colour temperature may be calculated
@@ -97,7 +97,7 @@ These two quantities, :math:`T_{\mathrm{R}}` and :math:`W` are vital for the
calculation of the plasma state of the ejecta (see :doc:`Plasma State
Calulation <../physics/plasma/index>`).
-Finally, TARDIS also reconstruct the mean intensity of the radiation field in
+Finally, TARDIS also reconstructs the mean intensity of the radiation field in
the blue wing of each line transition :math:`l \rightarrow u`, which is used in
the Macro Atom treatment and in the ionisation calculation.
@@ -106,7 +106,7 @@ the Macro Atom treatment and in the ionisation calculation.
J_{lu}^b = \frac{1}{4\pi \Delta V \Delta t} \frac{t_{\mathrm{exp}}}{c} \sum_i \frac{\varepsilon_i}{\nu_{lu}} D_{\mu}.
The summation here only involves packets which passed through the Sobolev point
-(see :doc:`Propagation `) of the transition. For a derivation of this
+(see :doc:`Propagation `) of the transition. For a derivation of this
estimator, in particular, for a motivation of the expansion factor involving
the time since explosion :math:`t_{\mathrm{exp}}`, we refer to
:cite:`Lucy2003`, section 6.2.
diff --git a/docs/physics/montecarlo/index.rst b/docs/physics/montecarlo/index.rst
index 2f05c796781..9f5c3faf8c5 100644
--- a/docs/physics/montecarlo/index.rst
+++ b/docs/physics/montecarlo/index.rst
@@ -7,7 +7,7 @@ transfer techniques as they are used in TARDIS. All the information listed here
can also be found in various papers by L. Lucy and in the main TARDIS publication
(c.f. :cite:`Abbott1985`, :cite:`Mazzali1993`, :cite:`Lucy1999`,
:cite:`Long2002`, :cite:`Lucy2002`, :cite:`Lucy2003`, :cite:`Lucy2005`,
-:cite:`Kerzendorf2014`)
+:cite:`Kerzendorf2014`).
.. toctree::
basicprinciples
diff --git a/docs/physics/montecarlo/lineinteraction.rst b/docs/physics/montecarlo/lineinteraction.rst
index 3d3be867e81..57b42fa2e74 100644
--- a/docs/physics/montecarlo/lineinteraction.rst
+++ b/docs/physics/montecarlo/lineinteraction.rst
@@ -8,7 +8,7 @@ treatment, a number of steps are always carried out when a Monte Carlo packet
performs a line interaction. Since TARDIS adopts the indivisible energy packet
formalism (see :doc:`Discretization `), the packet will have the
same energy in the co-moving frame after (f for final) the line interaction as
-before (i for initial). Thus, after accounting for the frame transformations
+before (i for initial). Thus, after accounting for the frame transformations,
.. math::
@@ -30,8 +30,8 @@ as an isotropic process. Thus,
.. note::
- Strictly speaking the re-mission process occurs in the local co-moving
- frame. Thus, the so called angle abberration effect should be taken into
+ Strictly speaking, the re-mission process occurs in the local co-moving
+ frame. Thus, the so called angle aberration effect should be taken into
account when transforming into the lab frame. However, TARDIS, currently
neglects this effect.
@@ -58,7 +58,7 @@ The so-called downbranching scheme, introduced by :cite:`Lucy1999a`, is an
elegant approach to approximately account for fluorescence effects. In this
scheme, the packet is not re-emitted in the same transitions as it was absorbed
in. Instead, it now can emerge from any line transition linking the activated
-upper energy level to a lower one. For any specific line interaction event the
+upper energy level to a lower one. For any specific line interaction event, the
re-emission channel is probabilistically selected according to the branching
ratios of the different allowed de-excitation transitions. For more details
about the downbranching scheme, we refer to :cite:`Lucy1999a` and
@@ -74,7 +74,7 @@ fluorescence processes and multi-line effects. Once a Monte Carlo packet is
absorbed in a certain line transition (macro atom activation), an arbitrary
number of internal jumps up and downwards may be performed. One may think of
them as changing the energy level which is excited. At any point during this
-process, there is the change that the internal jump procedure terminates and
+process, there is the chance that the internal jump procedure terminates and
that the packet is re-emitted in a transition linking the currently excited
upper energy level to a lower one (macro atom deactivation). Again, all
involved processes are governed by probabilities reflecting the different line
@@ -88,7 +88,7 @@ Comparison
==========
The different levels of sophistication are illustrated in the following plot,
-taken from :cite:`Kerzendorf2014` and showing the incident and versus the
+taken from :cite:`Kerzendorf2014` and showing the incident wavelength versus the
emergent wavelength of Monte Carlo packets in line interactions. The left panel
shows the situation in the resonant scatter mode, the middle one for the
downbranching scheme and the right one the macro atom results.
diff --git a/docs/physics/montecarlo/propagation.rst b/docs/physics/montecarlo/propagation.rst
index 1a5b98f7989..3859e6e97e9 100644
--- a/docs/physics/montecarlo/propagation.rst
+++ b/docs/physics/montecarlo/propagation.rst
@@ -7,7 +7,7 @@ determining the propagation history of the different packets. After a packet is
initialised, it is launched and may then perform interactions with the
surrounding material. This occurs again in a probabilistic manner. The packet
propagation is followed until it escapes through the outer boundary of the
-computational domain at which point the packet contributes to the synthetic
+computational domain, at which point the packet contributes to the synthetic
spectrum, the main product of a TARDIS calculation. The different spectral
features are simply a combined product of the changes in the packet properties
induced in the radiation-matter interactions.
@@ -93,7 +93,7 @@ interaction into a physical distance is not straight-forward in the presence of
frequency-dependent interaction process such as atomic line interactions. The
detailed procedure is outlined in the following section.
-In addition to the physical processes, numerical events which are a consequence
+In addition to the physical processes, numerical events that are a consequence
of the spatial discretization of the computational domain require interrupting
the propagating process. In TARDIS, as in many other numerical codes, physical
quantities are stored on a discrete mesh. Within the different cells, which in
@@ -105,7 +105,7 @@ new state of the ambient material. Thus, during the packet propagation, the
distance to the next radial shell is tracked to predict when the packet crosses
into a new shell. Special care is taken at the edges of the computational
domain. If a packet crosses back into the photosphere, it is discarded. Its
-propagation is stopped and it is no longer considered. Instead processing the
+propagation is stopped and it is no longer considered. Instead, processing the
next packet of the population is started. Similarly, the propagation is stopped
if the packet escapes through the outer surface of the domain. However, in this
case the packet contributes to the final emergent spectrum (see :doc:`Spectrum
@@ -123,8 +123,7 @@ supernovae.
Since the main focus of TARDIS is to calculate optical spectra,
electron-scatterings are treated in the elastic low-energy limit as classical
-Thomson scatterings. In this case, the electron scattering process is frequency
-independent. It's opacity only depends on the number density of free electrons
+Thomson scatterings. In this case, the electron scattering process is frequency-independent. Its opacity only depends on the number density of free electrons
:math:`n_e`
.. math::
@@ -140,7 +139,7 @@ Thomson scattering according to
\Delta \tau = \sigma_{\mathrm{T}} l.
-The situation is complicated by the inclusion of frequency dependent
+The situation is complicated by the inclusion of frequency-dependent
bound-bound interactions, i.e. interactions with atomic line transitions.
Photons and thus Monte Carlo packets can only interact with a line transition
if their frequency in the co-moving frame (see :doc:`Reference Frames
@@ -148,12 +147,12 @@ if their frequency in the co-moving frame (see :doc:`Reference Frames
atomic levels linked by the transition, i.e. if it comes into resonance. As a
photon/packet propagates through the homologously expanding ejecta, its
co-moving frame frequency is continuously red-shifted. Thus, during its
-propagation through the SN ejecta, a photon/packet may come into resonance with
+propagation through the supernova ejecta, a photon/packet may come into resonance with
many line transitions. This and the fact that line transitions have a finite
width given by the line profile function (in the case at hand, this width is
mainly given by thermal broadening) would render the determination of the line
optical depth accumulated along the photon/packet trajectory a complicated
-task. Fortunately, the typical conditions in supernova ejecta warrant the use
+task. Fortunately, the typical conditions in supernova ejecta warrant the use
of the so-called Sobolev approximation (see :doc:`Sobolev Approximation
<../physics/sobolev>`). Roughly speaking, this approximation replaces the line
profile function with a :math:`\delta` distribution around the natural line
@@ -167,16 +166,16 @@ With these assumptions, the calculation of the optical depth a packet
accumulates along its trajectory currently adopted in TARDIS proceeds according
to the following scheme (which was originally introduced by :cite:`Mazzali1993`):
given the current lab-frame frequency of the packet, the distance to the next
-Sobolev point (i.e. to the next line resonance) is calculated
+Sobolev point (i.e. to the next line resonance) is calculated.
Until this location, the packet continuously accumulates optical depth due to
electron-scattering. At the Sobolev point, the accumulated optical depth is
instantaneously incremented by the full line optical depth. Afterwards, the
-procedure is repeated, now with respect to next transition in the
+procedure is repeated, now with respect to the next transition in the
frequency-ordered list of all possible atomic line transitions. The point at
which the accumulated optical depth surpasses the value determined in the
random number experiment described above (determining the distance to the next
-physical interaction), determines the type of interaction the packet performs
+physical interaction) determines the type of interaction the packet performs
and at which location in the spatial mesh. The entire process is summarized in
the sketch below (taken from :cite:`Noebauer2014`, adapted from
:cite:`Mazzali1993`):
@@ -206,7 +205,7 @@ sampled according to
\mu_f = 2 z - 1.
-In addition, energy conservation has in the local co-moving frame has to be
+In addition, energy conservation in the local co-moving frame has to be
obeyed. Thus, the packets energy and frequency in the lab-frame suffer from the
relativistic Doppler shift
@@ -223,7 +222,7 @@ Line interactions proceed in a similar fashion. Since we assume that the
re-emission process occurs isotropically as well, the same directional sampling
as described above is used. Energy conservation again dictates how the packet
energy after the line interaction event is determined. The important difference
-is the assignment of the post interaction frequency. This depends on the
+is the assignment of the post-interaction frequency. This depends on the
selected line interaction mode (see :doc:`Line Interaction Modes
`).
@@ -232,7 +231,7 @@ selected line interaction mode (see :doc:`Line Interaction Modes
Note that the inclusion of special relativistic effects in TARDIS is at
best to first order in :math:`\beta`.
-Implementation: Main Propagation loop
+Implementation: Main Propagation Loop
=====================================
In summary of the concepts outlined above, the main Monte Carlo process within
@@ -246,8 +245,8 @@ radiation field emitted by the photosphere in the following way:
* the packet covers the shorter of these two distances:
* if the new shell is reached first, propagate into the shell and recalculate both distances
* if the packet has crossed through the inner domain boundary (photosphere), terminate propagation
- * likewise in case the packet escapes through outer boundary (ejecta surface): account for contribution to emergent spectrum and terminate propagation
- * if the interaction location is reached first, propagated to this location, perform interaction and recalculate both distances
+ * likewise, in case the packet escapes through the outer boundary (ejecta surface): account for contribution to emergent spectrum and terminate propagation
+ * if the interaction location is reached first, propagate to this location, perform interaction and recalculate both distances
* repeat this procedure until one of the two termination events occurs
The following flow chart summarizes this process again:
diff --git a/docs/physics/montecarlo/randomsampling.rst b/docs/physics/montecarlo/randomsampling.rst
index 9fbcd1eccea..0c626897563 100644
--- a/docs/physics/montecarlo/randomsampling.rst
+++ b/docs/physics/montecarlo/randomsampling.rst
@@ -13,34 +13,34 @@ Number Generators are available. These produce (pseudo-) random numbers
:math:`z` uniformly distributed on the interval :math:`[0,1]`. The challenge
now lies in using these numbers to sample any physical process involved in the
Radiative transfer calculation. From a probability theory point of view, this
-just implies finding mapping between the probability distribution governing the
-physical process and the one underlying the Random number generator. This
+just implies finding a mapping between the probability distribution governing the
+physical process and the one underlying the Random Number Generator. This
process is typically referred to as random sampling.
Inverse transformation method
=============================
.. note::
- This is a very superficial and sloppy description Random sampling. More
+ This is a very superficial and sloppy description of Random sampling. More
detailed and rigorous accounts are found in the standard literature, for
- example in :cite:`Kalos2008`
+ example in :cite:`Kalos2008`.
-The simplest and most used technique in Monte Carlo radiative transfer
+The simplest and most-used technique in Monte Carlo radiative transfer
applications is referred to as the inverse transformation method and involves
the cumulative distribution function. In general, a random process captured by
the random variable :math:`X` is governed by a probability density
:math:`\rho_X(x)` (the continuous counterpart to discrete probabilities), with
:math:`\rho_X(x) \mathrm{d}x` describing the probability of the variable taking
values in the interval :math:`[x, x+\mathrm{d}x]`. The cumulative distribution
-function in turn describes, as the name suggests the probability of the
-variable taking the any value between :math:`-\infty` and :math:`x`:
+function in turn describes, as the name suggests, the probability of the
+variable taking any value between :math:`-\infty` and :math:`x`:
.. math::
f_X(x) = \int_{-\infty}^x \mathrm{d}x \rho_X(x)
Since the probability density is by definition always positive, the cumulative
-distribution function is monotonously increasing. This constitutes the basis
+distribution function is monotonically increasing. This constitutes the basis
for the inverse transformation function. Consider two random variables,
:math:`X` and :math:`Y`. A mapping between those may be established by equating
their cumulative distribution functions. Numbers :math:`y` distributed
@@ -56,7 +56,7 @@ function is trivial, namely :math:`f_Z(z) = z`. However, the inverse
distribution sampling method relies on finding the analytic inverse function of
the cumulative distribution function governing the physical processes to be
sampled. If this is not possible, other sampling methods, such as von-Neumann
-rejection sampling techniques have to be used.
+rejection sampling techniques, have to be used.
Examples
========
diff --git a/docs/physics/montecarlo/sourceintegration.rst b/docs/physics/montecarlo/sourceintegration.rst
index f5b4d9b3f3a..165f6e5129e 100644
--- a/docs/physics/montecarlo/sourceintegration.rst
+++ b/docs/physics/montecarlo/sourceintegration.rst
@@ -8,7 +8,7 @@ Direct integration of the radiation field
synthetic supernova spectra. Instead of using the frequency and energy of
virtual Monte Carlo (MC) packets to create a spectrum through binning, one can
formally integrate the line source functions which can be calculated from
-volume based estimators collected during the MC simulation. Spectra generated
+volume-based estimators collected during the MC simulation. Spectra generated
using this method are virtually noise-free. However, statistical fluctuations
inherent to Monte Carlo calculations still affect the determination of the
source functions and thus indirectly introduce an uncertainty in the spectral
@@ -53,10 +53,10 @@ Finally, the line source function for each transition can be derived with
\dot E_u
Here, :math:`\lambda_{ul}` is the wavelength of the line :math:`u \rightarrow
-l`, and :math:`q_{ul}` is the corresponding branching ratio, i.e.\ the fraction
+l`, and :math:`q_{ul}` is the corresponding branching ratio, i.e. the fraction
of de-excitations of level :math:`u` proceeding via the transition
:math:`u\rightarrow l`. For convenience, the attenuating factor is kept on the
-left hand side because it is the product of the two that will appear in later
+left-hand side because it is the product of the two that will appear in later
formulae.
Finally, if the contribution by electron-scattering has to be taken into
@@ -129,10 +129,10 @@ Implementation Details
We seek to integrate all emissions at a certain wavelength :math:`\nu` along a
ray with impact parameter :math:`p`. Because the supernova ejecta is expanding
homologously, the co-moving frame frequency is continuously shifted to longer
-wavelength due to the relativistic Doppler effect as the packet/photon
+wavelengths due to the relativistic Doppler effect as the packet/photon
propagates.
-To find out, which lines can shift into the target frequency, we need to
+To find out which lines can shift into the target frequency, we need to
calculate the maximum Doppler shift along a given ray. At any point, the
Doppler effect in our coordinates is
@@ -159,7 +159,7 @@ and in turn :math:`z_c` can be given as
z_c = \sqrt{r_c^2 + p_c^2}
-where the subscripts indicate the value at point C. By symmetry the
+where the subscripts indicate the value at point C. By symmetry, the
intersection point for negative :math:`z` is simply :math:`-z_c`.
Using the expression for :math:`\mu`, :math:`\beta` above leads to the
@@ -169,7 +169,7 @@ dependence on :math:`r` cancelling, and solving for :math:`\nu_0` gives
\nu_0 = \frac{\nu}{1 + \frac{z}{ct}}
-For any given shell and impact parameter we can thus find the maximum and
+For any given shell and impact parameter, we can thus find the maximum and
minimum co-moving frequency that will give the specified lab frame frequency.
This allows us to find the section of the line list with the transitions whose
resonances have to be considered in the calculation of the limiting specific
@@ -185,7 +185,7 @@ The current implementation of the formal integral has some limitations:
otherwise the :math:`J^b` and :math:`J^r` do not provide an accurate
representation of the diffuse radiation field at the current location on the
ray. Also, :math:`d\tau` can become large which can create unphysical,
- negative intensities
+ negative intensities.
It is always advised to check the results of the formal integration against the
spectrum constructed from the emerging Monte Carlo packets.
diff --git a/docs/physics/montecarlo/virtualpackets.rst b/docs/physics/montecarlo/virtualpackets.rst
index 1b1f7fce41b..b92c23b00cd 100644
--- a/docs/physics/montecarlo/virtualpackets.rst
+++ b/docs/physics/montecarlo/virtualpackets.rst
@@ -9,7 +9,7 @@ two methods are implemented to calculate the spectrum during the main Monte
Carlo calculation. One follows the obvious approach of recording the properties
of all escaping Monte Carlo packets and binning their contributions in
frequency (or wavelength) space. This "real packet" spectrum will naturally
-suffer from Monte Carlo noise and if one tries to improve its signal-to-noise
+suffer from Monte Carlo noise, and if one tries to improve its signal-to-noise
ratio, one immediately encounters a fundamental characteristic of Monte Carlo
approaches. Since Monte Carlo processes are typically governed by Poisson
statistics, the level of stochastic fluctuations decreases only as :math:`\propto
@@ -59,7 +59,7 @@ optical depth. In particular, it contributes with the
to the emergent luminosity in the frequency interval :math:`[\nu, \nu + \Delta
\nu]`. Here, :math:`\Delta t` denotes the physical duration of the simulation
step (the same duration which is used during the initialization process at the
-photosphere, see :doc:`Propagation `) and :math:`\varepsilon` is
+photosphere, see :doc:`Propagation `), and :math:`\varepsilon` is
the energy of the virtual packet when it was generated.
.. note::
@@ -71,7 +71,7 @@ the energy of the virtual packet when it was generated.
The initialization process for virtual packets is slightly different from real
ones. For example, whenever a real packet is emitted by the photosphere,
-:math:`N_v` virtual packets are spawned as well. The propagation direction of
+:math:`N_v` virtual packets are spawned, as well. The propagation direction of
these virtual packets is assigned uniformly. However, since :math:`N_v` is
typically small, an unequal sampling of the solid angle is avoided by selecting
:math:`N_v` equal :math:`\mu` bins and sampling the direction uniformly within
@@ -116,10 +116,10 @@ problem :
I(R, \mu, \nu) = I(R_{\mathrm{phot}}, \mu, \nu) \exp(-\tau(s_0)) +
\int_0^{s_0} \eta(R - \mu s, \mu, \nu) \exp(-\tau(s)) \mathrm{d}s
-This formulation of the formal solution is valid for the SN ejecta problem and
+This formulation of the formal solution is valid for the supernova ejecta problem and
involves the location of the photosphere, the radius of the ejecta surface
:math:`R` and the packet trajectory :math:`s`. Here, the optical depth
-:math:`\tau(s)` measures the optical depth from :math:`s` to the ejecta surface
+:math:`\tau(s)` measures the optical depth from :math:`s` to the ejecta surface.
For more details see :doc:`Radiative Transfer Primer
<../physics/radiativetransfer>`.
diff --git a/docs/physics/montecarlo_old.rst b/docs/physics/montecarlo_old.rst
index 6075f2e69bf..5425fdd23fc 100644
--- a/docs/physics/montecarlo_old.rst
+++ b/docs/physics/montecarlo_old.rst
@@ -6,34 +6,34 @@ Radiative Monte Carlo
.. :currentmodule:: tardis.montecarlo_multizone
-We assume the supernova is in homologous expansion and we assume that
-there is photon injection from an inner boundary and we assume an outer boundary
+We assume the supernova is in homologous expansion, and we assume that
+there is photon injection from an inner boundary, and we assume an outer boundary
where these photons can leave the simulation again.
-Montecarlo packets
-^^^^^^^^^^^^^^^^^^
+Monte Carlo packets
+^^^^^^^^^^^^^^^^^^^
-Montecarlo packets have a frequency, angle (:math:`\mu=\cos{\theta}` )
-and an energy: :math:`P(\nu, \mu, \epsilon)`. A large number :math:`n` are generated
-at the start of each Montecarlo run in TARDIS by drawing :math:`\nu` from a
+Monte Carlo packets have a frequency, angle (:math:`\mu=\cos{\theta}` )
+and an energy: :math:`P(\nu, \mu, \epsilon)`. A large number :math:`n` is generated
+at the start of each Monte Carlo run in TARDIS by drawing :math:`\nu` from a
black-body distribution distribution with a :math:`\mu` being drawn from a
:math:`\sqrt[2]{z}` distribution and an
energy that is :math:`1/n`.
-These packets are then launched into the simulation and there are two possible
+These packets are then launched into the simulation, and there are two possible
outcomes for each packet.
- * **packet leaves the simulation through the outer bound** and count towards the
+ * **packet leaves the simulation through the outer bound** and counts towards the
spectrum
- * **packet leaves the simulation through the inner boundary** and are lost
+ * **packet leaves the simulation through the inner boundary** and is lost
(reabsorbed)
-The packets can gain and loose energy throughout the simulation. If these packets
-scatter (through the various mechanisms), we transform into the comoving frame at
-that position :math:`v(r) = r / t_\textrm{explosion}`, where :math:`t_explosion`
-is the time since explosion with the doppler factor
-:math:`d_\textrm{rest \rightarrow comoving}` then change direction from
+The packets can gain and lose energy throughout the simulation. If these packets
+scatter (through the various mechanisms), we transform into the co-moving frame at
+that position :math:`v(r) = r / t_\textrm{explosion}`, where :math:`t_\textrm{explosion}`
+is the time since explosion with the Doppler factor
+:math:`d_\textrm{rest \rightarrow comoving}`, then change direction from
:math:`\mu_\textrm{in}` to :math:`mu_\textrm{out}` and transform back and
change the energy accordingly:
@@ -42,7 +42,7 @@ change the energy accordingly:
d_\textrm{rest \rightarrow comoving} = 1 - \mu_\textrm{out} v(r) / c \\
E_\textrm{after scatter} = E_\textrm{before scatter} \times \frac{1 - \mu_\textrm{in} v(r) / c}{1 - \mu_\textrm{out} v(r) / c}
-This way the montecarlo packets can gain or loose energy in the simulation:
+This way, the Monte Carlo packets can gain or lose energy in the simulation:
.. plot:: physics/pyplot/plot_mu_in_out_packet.py
@@ -50,15 +50,15 @@ This way the montecarlo packets can gain or loose energy in the simulation:
The spectrum is then generated as a weighted histogram. For each bin with edges
-:math:`\nu_{n}, \nu_{n+1}` we get all the packets that left the simulation through
+:math:`\nu_{n}, \nu_{n+1}`, we get all the packets that left the simulation through
the outer boundary and add up their remaining energies.
-Montecarlo Geometry
-^^^^^^^^^^^^^^^^^^^
+Monte Carlo Geometry
+^^^^^^^^^^^^^^^^^^^^
-Before any packet action is performed we calculate four different distances
+Before any packet action is performed, we calculate four different distances
( :math:`d_\textrm{inner}, d_\textrm{outer}, d_\textrm{line}, d_{\textrm{e}^{-}}` )
The calculations for the distance to the outer boundary:
@@ -73,23 +73,23 @@ The calculations for the distance to the inner boundary:
-Radiationfield estimators
+Radiation field estimators
^^^^^^^^^^^^^^^^^^^^^^^^^
-During the monte-carlo run we collect two estimators for the radiation field:
+During the Monte Carlo run, we collect two estimators for the radiation field:
.. math::
J_\textrm{estimator} &= \sum{\epsilon l}\\
\bar{\nu}_\textrm{estimator} &= \sum{\epsilon \nu l},
-where :math:`\epsilon, \nu` are comoving energy and comoving frequency of a packet respectively.
+where :math:`\epsilon, \nu` are co-moving energy and co-moving frequency of a packet, respectively.
-To calculate the temperature and dilution factor we first calculate the mean intensity in each cell
+To calculate the temperature and dilution factor, we first calculate the mean intensity in each cell
( :math:`J = \frac{1}{4\pi\, \Delta t\, V} J_\textrm{estimator}` )., :cite:`2003A&A...403..261L`.
The weighted mean frequency is used to obtain the radiation temperature. Specifically, the radiation temperature is chosen as the
-temperature of a black body that has the same weighted mean frequency as has been computed in the simulation. Accordingly,
+temperature of a black-body that has the same weighted mean frequency as has been computed in the simulation. Accordingly,
.. math::
@@ -110,14 +110,14 @@ and so
T_{R} &= \frac{1}{\bar{x}} \frac{h}{k_{B}} \frac{\bar{\nu}_\textrm{estimator}}{J_\textrm{estimator}} \\
&= 0.260945 \frac{h}{k_{B}} \frac{\bar{\nu}_\textrm{estimator}}{J_\textrm{estimator}}.
-With the radiation temperature known, we can then obtain our estimate for for the dilution factor. Our radiation field model in the
-nebular approximation is
+With the radiation temperature known, we can then obtain our estimate for the dilution factor. Our radiation field model in the
+nebular approximation is:
.. math::
J = W B(T_{R}) = W \frac{\sigma_{SB}}{\pi} T_{R}^4,
-i.e. a dilute blackbody. Therefore we use our value of the mean intensity derrived from the estimator (above) to obtain the
+i.e., a dilute black-body. Therefore we use our value of the mean intensity derived from the estimator (above) to obtain the
dilution factor
.. math::
diff --git a/docs/physics/new_plasma.rst b/docs/physics/new_plasma.rst
index d55a83557ad..d15117b5944 100644
--- a/docs/physics/new_plasma.rst
+++ b/docs/physics/new_plasma.rst
@@ -6,9 +6,9 @@ The role of the plasma module is to determine the ionisation and excitation stat
supernova ejecta, given the basic structure, including the elemental abundances, densities and radiation temperature.
After the calculation of the plasma state, the :math:`\tau_{\textrm{sobolev}}` values can be calculated.
-The Tardis plasma structure inherits from the `BasePlasma class`. The code currently uses the `LegacyPlasmaArray`
+The TARDIS plasma structure inherits from the `BasePlasma` class. The code currently uses the `LegacyPlasmaArray`
for generating a plasma from the information provided by `model`. A variety of different plasmas can be generated
-depending on the options selected in the plasma section of the Tardis config. file. The options currently considered
+depending on the options selected in the plasma section of the TARDIS config. file. The options currently considered
by the Legacy Plasma when creating the plasma calculation structure include:
plasma:
@@ -18,11 +18,11 @@ plasma:
* helium_treatment: dilute-lte/recomb-nlte
* nlte: [can provide list of ion species to be treated in NLTE, as well as specifying the use of the coronal_approximation/classical_nebular settings.
-`LegacyPlasmaArray` uses these options to construct a map of the necessary plasma parameters that demonstrates how these parameters are dependent on one another (using networkx). Each time a particular parameter of the plasma is updated, all of the parameters dependent (directly or indirectly) on that particular one can be easily updated automatically, without requiring that all the plasma calculations are repeated.
+`LegacyPlasmaArray` uses these options to construct a map of the necessary plasma parameters that demonstrates how these parameters are dependent on one another (using `NetworkX `_). Each time a particular parameter of the plasma is updated, all of the parameters dependent (directly or indirectly) on that particular one can be easily updated automatically, without requiring that all the plasma calculations are repeated.
Properties, Inputs and Outputs
------------------------------
-Each Tardis plasma possesses an array of plasma properties, which are used to calculate plasma parameter values. Most plasma properties have a single output, e.g.
+Each TARDIS plasma possesses an array of plasma properties, which are used to calculate plasma parameter values. Most plasma properties have a single output, e.g.
* `GElectron`: (`g_electron`,)
* `HeliumNLTE`: (`helium_population`,)
@@ -30,12 +30,12 @@ but some have two or more, e.g.
* `IonNumberDensity`: (`ion_number_density`, `electron_densities`)
* `Levels`: (`levels`, `excitation_energy`, `metastability`, `g`)
-Every property has a `calculate` function that returns the values of its outputs. The arguments required for that function become the property inputs. Tardis will raise an error if it does not have all of the required inputs for a particular property. It will also raise an error if there is an output loop, i.e. if two properties are dependent on each other. Some different properties share output names, for example, `PhiSahaLTE` and `PhiSahaNebular` both have an output called `phi`. That is because the `phi` value is calculated differently depending on the ionization method selected, but once calculated both values interact in the same way with the rest of the plasma. Tardis will import only one of the `phi` properties when initialising the plasma.
+Every property has a `calculate` function that returns the values of its outputs. The arguments required for that function become the property inputs. TARDIS will raise an error if it does not have all of the required inputs for a particular property. It will also raise an error if there is an output loop, i.e. if two properties are dependent on each other. Some different properties share output names; for example, `PhiSahaLTE` and `PhiSahaNebular` both have an output called `phi`. That is because the `phi` value is calculated differently depending on the ionization method selected, but once calculated, both values interact in the same way with the rest of the plasma. TARDIS will import only one of the `phi` properties when initialising the plasma.
The Plasma Graph
----------------
-If the necessary Python modules (pygraphviz and dot2tex) are available, Tardis will automatically output a .tex file at the beginning of each run that can be compiled to produce a PDF image of the plasma module graph. The nodes on this graph are the names of plasma properties, e.g. `Levels`, `TauSobolev`, `IonNumberDensity`, along with a list of outputs from those properties and equations showing how they are calculated. These nodes are connected by arrows linking nodes with the sources of their inputs, and labelled with the name of the input/output linking the two properties, e.g. `levels`, :math:`\tau_{\textrm{sobolev}}`, :math:`n_{e}`.
+If the necessary Python modules (`PyGraphviz `_ and `dot2tex `_) are available, TARDIS will automatically output a .tex file at the beginning of each run that can be compiled to produce a PDF image of the plasma module graph. The nodes on this graph are the names of plasma properties, e.g. `Levels`, `TauSobolev`, `IonNumberDensity`, along with a list of outputs from those properties and equations showing how they are calculated. These nodes are connected by arrows linking nodes with the sources of their inputs, and labelled with the name of the input/output linking the two properties, e.g. `levels`, :math:`\tau_{\textrm{sobolev}}`, :math:`n_{e}`.
Updating the Plasma
-------------------
-During each iteration of the main code, Tardis updates the plasma using the `update_radiationfield` function. This requires, at minimum, new values for `t_rad` (the radiation temperature), `w` (the dilution factor) and `j_blues` (the intensity in the blue part of each line).
+During each iteration of the main code, TARDIS updates the plasma using the `update_radiationfield` function. This requires, at minimum, new values for `t_rad` (the radiation temperature), `w` (the dilution factor) and `j_blues` (the intensity in the blue part of each line).
diff --git a/docs/physics/physical_quantities.ipynb b/docs/physics/physical_quantities.ipynb
index f136aef7d87..a98a716e7c0 100644
--- a/docs/physics/physical_quantities.ipynb
+++ b/docs/physics/physical_quantities.ipynb
@@ -11,10 +11,10 @@
"cell_type": "markdown",
"metadata": {},
"source": [
- "In order to compute the synthetic spectrum, Tardis must either be told\n",
+ "In order to compute the synthetic spectrum, TARDIS must either be told\n",
"or must calculate many physical properties of the model. To understand and\n",
"test the code it can be important to look at these values. One\n",
- "easy way to do this is to run Tardis in an interactive mode and then\n",
+ "easy way to do this is to run TARDIS in an interactive mode and then\n",
"inspect the model properties."
]
},
@@ -42,7 +42,7 @@
"name": "stdout",
"output_type": "stream",
"text": [
- "[\u001b[1mtardis.io.atom_data.atom_web_download\u001b[0m][\u001b[1;37mINFO\u001b[0m ] Downloading atomic data from https://media.githubusercontent.com/media/tardis-sn/tardis-refdata/master/atom_data/kurucz_cd23_chianti_H_He.h5 to /Users/sashmish/Downloads/tardis-data/kurucz_cd23_chianti_H_He.h5 (\u001b[1matom_web_download.py\u001b[0m:47)\n",
+ "[\u001B[1mtardis.io.atom_data.atom_web_download\u001B[0m][\u001B[1;37mINFO\u001B[0m ] Downloading atomic data from https://media.githubusercontent.com/media/tardis-sn/tardis-refdata/master/atom_data/kurucz_cd23_chianti_H_He.h5 to /Users/sashmish/Downloads/tardis-data/kurucz_cd23_chianti_H_He.h5 (\u001B[1matom_web_download.py\u001B[0m:47)\n",
" % Total % Received % Xferd Average Speed Time Time Time Current\n",
" Dload Upload Total Spent Left Speed\n",
"100 980 100 980 0 0 2222 0 --:--:-- --:--:-- --:--:-- 2222\n"
@@ -67,13 +67,13 @@
"name": "stdout",
"output_type": "stream",
"text": [
- "[\u001b[1mtardis.plasma.standard_plasmas\u001b[0m][\u001b[1;37mINFO\u001b[0m ] Reading Atomic Data from kurucz_cd23_chianti_H_He.h5 (\u001b[1mstandard_plasmas.py\u001b[0m:74)\n",
- "[\u001b[1mtardis.io.atom_data.util\u001b[0m][\u001b[1;37mINFO\u001b[0m ] Atom Data kurucz_cd23_chianti_H_He.h5 not found in local path. Exists in TARDIS Data repo /Users/sashmish/Downloads/tardis-data/kurucz_cd23_chianti_H_He.h5 (\u001b[1mutil.py\u001b[0m:29)\n",
- "[\u001b[1mtardis.io.atom_data.base\u001b[0m][\u001b[1;37mINFO\u001b[0m ] Read Atom Data with UUID=6f7b09e887a311e7a06b246e96350010 and MD5=864f1753714343c41f99cb065710cace. (\u001b[1mbase.py\u001b[0m:184)\n",
- "[\u001b[1mtardis.io.atom_data.base\u001b[0m][\u001b[1;37mINFO\u001b[0m ] Non provided atomic data: synpp_refs, photoionization_data (\u001b[1mbase.py\u001b[0m:187)\n",
- "[\u001b[1mtardis.simulation.base\u001b[0m][\u001b[1;37mINFO\u001b[0m ] Starting iteration 1/20 (\u001b[1mbase.py\u001b[0m:268)\n",
- "[\u001b[1mtardis.simulation.base\u001b[0m][\u001b[1;37mINFO\u001b[0m ] Luminosity emitted = 7.93730e+42 erg / s Luminosity absorbed = 2.66400e+42 erg / s Luminosity requested = 1.05928e+43 erg / s (\u001b[1mbase.py\u001b[0m:359)\n",
- "[\u001b[1mtardis.simulation.base\u001b[0m][\u001b[1;37mINFO\u001b[0m ] Plasma stratification:\n",
+ "[\u001B[1mtardis.plasma.standard_plasmas\u001B[0m][\u001B[1;37mINFO\u001B[0m ] Reading Atomic Data from kurucz_cd23_chianti_H_He.h5 (\u001B[1mstandard_plasmas.py\u001B[0m:74)\n",
+ "[\u001B[1mtardis.io.atom_data.util\u001B[0m][\u001B[1;37mINFO\u001B[0m ] Atom Data kurucz_cd23_chianti_H_He.h5 not found in local path. Exists in TARDIS Data repo /Users/sashmish/Downloads/tardis-data/kurucz_cd23_chianti_H_He.h5 (\u001B[1mutil.py\u001B[0m:29)\n",
+ "[\u001B[1mtardis.io.atom_data.base\u001B[0m][\u001B[1;37mINFO\u001B[0m ] Read Atom Data with UUID=6f7b09e887a311e7a06b246e96350010 and MD5=864f1753714343c41f99cb065710cace. (\u001B[1mbase.py\u001B[0m:184)\n",
+ "[\u001B[1mtardis.io.atom_data.base\u001B[0m][\u001B[1;37mINFO\u001B[0m ] Non provided atomic data: synpp_refs, photoionization_data (\u001B[1mbase.py\u001B[0m:187)\n",
+ "[\u001B[1mtardis.simulation.base\u001B[0m][\u001B[1;37mINFO\u001B[0m ] Starting iteration 1/20 (\u001B[1mbase.py\u001B[0m:268)\n",
+ "[\u001B[1mtardis.simulation.base\u001B[0m][\u001B[1;37mINFO\u001B[0m ] Luminosity emitted = 7.93730e+42 erg / s Luminosity absorbed = 2.66400e+42 erg / s Luminosity requested = 1.05928e+43 erg / s (\u001B[1mbase.py\u001B[0m:359)\n",
+ "[\u001B[1mtardis.simulation.base\u001B[0m][\u001B[1;37mINFO\u001B[0m ] Plasma stratification:\n",
"\t t_rad next_t_rad w next_w\n",
"\tShell \n",
"\t0 9926.501965 10168.422346 0.400392 0.501001\n",
@@ -81,11 +81,11 @@
"\t10 9779.813302 10222.882075 0.142695 0.113985\n",
"\t15 9708.082813 9928.649533 0.104556 0.085217\n",
"\n",
- " (\u001b[1mbase.py\u001b[0m:350)\n",
- "[\u001b[1mtardis.simulation.base\u001b[0m][\u001b[1;37mINFO\u001b[0m ] t_inner 9933.952 K -- next t_inner 11475.997 K (\u001b[1mbase.py\u001b[0m:352)\n",
- "[\u001b[1mtardis.simulation.base\u001b[0m][\u001b[1;37mINFO\u001b[0m ] Starting iteration 2/20 (\u001b[1mbase.py\u001b[0m:268)\n",
- "[\u001b[1mtardis.simulation.base\u001b[0m][\u001b[1;37mINFO\u001b[0m ] Luminosity emitted = 1.41371e+43 erg / s Luminosity absorbed = 4.73752e+42 erg / s Luminosity requested = 1.05928e+43 erg / s (\u001b[1mbase.py\u001b[0m:359)\n",
- "[\u001b[1mtardis.simulation.base\u001b[0m][\u001b[1;37mINFO\u001b[0m ] Plasma stratification:\n",
+ " (\u001B[1mbase.py\u001B[0m:350)\n",
+ "[\u001B[1mtardis.simulation.base\u001B[0m][\u001B[1;37mINFO\u001B[0m ] t_inner 9933.952 K -- next t_inner 11475.997 K (\u001B[1mbase.py\u001B[0m:352)\n",
+ "[\u001B[1mtardis.simulation.base\u001B[0m][\u001B[1;37mINFO\u001B[0m ] Starting iteration 2/20 (\u001B[1mbase.py\u001B[0m:268)\n",
+ "[\u001B[1mtardis.simulation.base\u001B[0m][\u001B[1;37mINFO\u001B[0m ] Luminosity emitted = 1.41371e+43 erg / s Luminosity absorbed = 4.73752e+42 erg / s Luminosity requested = 1.05928e+43 erg / s (\u001B[1mbase.py\u001B[0m:359)\n",
+ "[\u001B[1mtardis.simulation.base\u001B[0m][\u001B[1;37mINFO\u001B[0m ] Plasma stratification:\n",
"\t t_rad next_t_rad w next_w\n",
"\tShell \n",
"\t0 10168.422346 11497.903617 0.501001 0.545136\n",
@@ -93,11 +93,11 @@
"\t10 10222.882075 11335.692704 0.113985 0.135635\n",
"\t15 9928.649533 11018.841465 0.085217 0.101203\n",
"\n",
- " (\u001b[1mbase.py\u001b[0m:350)\n",
- "[\u001b[1mtardis.simulation.base\u001b[0m][\u001b[1;37mINFO\u001b[0m ] t_inner 11475.997 K -- next t_inner 9933.797 K (\u001b[1mbase.py\u001b[0m:352)\n",
- "[\u001b[1mtardis.simulation.base\u001b[0m][\u001b[1;37mINFO\u001b[0m ] Starting iteration 3/20 (\u001b[1mbase.py\u001b[0m:268)\n",
- "[\u001b[1mtardis.simulation.base\u001b[0m][\u001b[1;37mINFO\u001b[0m ] Luminosity emitted = 8.04734e+42 erg / s Luminosity absorbed = 2.55640e+42 erg / s Luminosity requested = 1.05928e+43 erg / s (\u001b[1mbase.py\u001b[0m:359)\n",
- "[\u001b[1mtardis.simulation.base\u001b[0m][\u001b[1;37mINFO\u001b[0m ] Plasma stratification:\n",
+ " (\u001B[1mbase.py\u001B[0m:350)\n",
+ "[\u001B[1mtardis.simulation.base\u001B[0m][\u001B[1;37mINFO\u001B[0m ] t_inner 11475.997 K -- next t_inner 9933.797 K (\u001B[1mbase.py\u001B[0m:352)\n",
+ "[\u001B[1mtardis.simulation.base\u001B[0m][\u001B[1;37mINFO\u001B[0m ] Starting iteration 3/20 (\u001B[1mbase.py\u001B[0m:268)\n",
+ "[\u001B[1mtardis.simulation.base\u001B[0m][\u001B[1;37mINFO\u001B[0m ] Luminosity emitted = 8.04734e+42 erg / s Luminosity absorbed = 2.55640e+42 erg / s Luminosity requested = 1.05928e+43 erg / s (\u001B[1mbase.py\u001B[0m:359)\n",
+ "[\u001B[1mtardis.simulation.base\u001B[0m][\u001B[1;37mINFO\u001B[0m ] Plasma stratification:\n",
"\t t_rad next_t_rad w next_w\n",
"\tShell \n",
"\t0 11497.903617 10477.653343 0.545136 0.439296\n",
@@ -105,11 +105,11 @@
"\t10 11335.692704 10635.474976 0.135635 0.100253\n",
"\t15 11018.841465 10290.254692 0.101203 0.075529\n",
"\n",
- " (\u001b[1mbase.py\u001b[0m:350)\n",
- "[\u001b[1mtardis.simulation.base\u001b[0m][\u001b[1;37mINFO\u001b[0m ] t_inner 9933.797 K -- next t_inner 11397.084 K (\u001b[1mbase.py\u001b[0m:352)\n",
- "[\u001b[1mtardis.simulation.base\u001b[0m][\u001b[1;37mINFO\u001b[0m ] Starting iteration 4/20 (\u001b[1mbase.py\u001b[0m:268)\n",
- "[\u001b[1mtardis.simulation.base\u001b[0m][\u001b[1;37mINFO\u001b[0m ] Luminosity emitted = 1.38199e+43 erg / s Luminosity absorbed = 4.54590e+42 erg / s Luminosity requested = 1.05928e+43 erg / s (\u001b[1mbase.py\u001b[0m:359)\n",
- "[\u001b[1mtardis.simulation.base\u001b[0m][\u001b[1;37mINFO\u001b[0m ] Plasma stratification:\n",
+ " (\u001B[1mbase.py\u001B[0m:350)\n",
+ "[\u001B[1mtardis.simulation.base\u001B[0m][\u001B[1;37mINFO\u001B[0m ] t_inner 9933.797 K -- next t_inner 11397.084 K (\u001B[1mbase.py\u001B[0m:352)\n",
+ "[\u001B[1mtardis.simulation.base\u001B[0m][\u001B[1;37mINFO\u001B[0m ] Starting iteration 4/20 (\u001B[1mbase.py\u001B[0m:268)\n",
+ "[\u001B[1mtardis.simulation.base\u001B[0m][\u001B[1;37mINFO\u001B[0m ] Luminosity emitted = 1.38199e+43 erg / s Luminosity absorbed = 4.54590e+42 erg / s Luminosity requested = 1.05928e+43 erg / s (\u001B[1mbase.py\u001B[0m:359)\n",
+ "[\u001B[1mtardis.simulation.base\u001B[0m][\u001B[1;37mINFO\u001B[0m ] Plasma stratification:\n",
"\t t_rad next_t_rad w next_w\n",
"\tShell \n",
"\t0 10477.653343 11608.211738 0.439296 0.506501\n",
@@ -117,11 +117,11 @@
"\t10 10635.474976 11479.604579 0.100253 0.125779\n",
"\t15 10290.254692 11149.192411 0.075529 0.094052\n",
"\n",
- " (\u001b[1mbase.py\u001b[0m:350)\n",
- "[\u001b[1mtardis.simulation.base\u001b[0m][\u001b[1;37mINFO\u001b[0m ] t_inner 11397.084 K -- next t_inner 9978.058 K (\u001b[1mbase.py\u001b[0m:352)\n",
- "[\u001b[1mtardis.simulation.base\u001b[0m][\u001b[1;37mINFO\u001b[0m ] Starting iteration 5/20 (\u001b[1mbase.py\u001b[0m:268)\n",
- "[\u001b[1mtardis.simulation.base\u001b[0m][\u001b[1;37mINFO\u001b[0m ] Luminosity emitted = 8.16431e+42 erg / s Luminosity absorbed = 2.62454e+42 erg / s Luminosity requested = 1.05928e+43 erg / s (\u001b[1mbase.py\u001b[0m:359)\n",
- "[\u001b[1mtardis.simulation.base\u001b[0m][\u001b[1;37mINFO\u001b[0m ] Plasma stratification:\n",
+ " (\u001B[1mbase.py\u001B[0m:350)\n",
+ "[\u001B[1mtardis.simulation.base\u001B[0m][\u001B[1;37mINFO\u001B[0m ] t_inner 11397.084 K -- next t_inner 9978.058 K (\u001B[1mbase.py\u001B[0m:352)\n",
+ "[\u001B[1mtardis.simulation.base\u001B[0m][\u001B[1;37mINFO\u001B[0m ] Starting iteration 5/20 (\u001B[1mbase.py\u001B[0m:268)\n",
+ "[\u001B[1mtardis.simulation.base\u001B[0m][\u001B[1;37mINFO\u001B[0m ] Luminosity emitted = 8.16431e+42 erg / s Luminosity absorbed = 2.62454e+42 erg / s Luminosity requested = 1.05928e+43 erg / s (\u001B[1mbase.py\u001B[0m:359)\n",
+ "[\u001B[1mtardis.simulation.base\u001B[0m][\u001B[1;37mINFO\u001B[0m ] Plasma stratification:\n",
"\t t_rad next_t_rad w next_w\n",
"\tShell \n",
"\t0 11608.211738 10556.913414 0.506501 0.440229\n",
@@ -129,11 +129,11 @@
"\t10 11479.604579 10713.104080 0.125779 0.099268\n",
"\t15 11149.192411 10399.079825 0.094052 0.073482\n",
"\n",
- " (\u001b[1mbase.py\u001b[0m:350)\n",
- "[\u001b[1mtardis.simulation.base\u001b[0m][\u001b[1;37mINFO\u001b[0m ] t_inner 9978.058 K -- next t_inner 11365.561 K (\u001b[1mbase.py\u001b[0m:352)\n",
- "[\u001b[1mtardis.simulation.base\u001b[0m][\u001b[1;37mINFO\u001b[0m ] Starting iteration 6/20 (\u001b[1mbase.py\u001b[0m:268)\n",
- "[\u001b[1mtardis.simulation.base\u001b[0m][\u001b[1;37mINFO\u001b[0m ] Luminosity emitted = 1.36136e+43 erg / s Luminosity absorbed = 4.54590e+42 erg / s Luminosity requested = 1.05928e+43 erg / s (\u001b[1mbase.py\u001b[0m:359)\n",
- "[\u001b[1mtardis.simulation.base\u001b[0m][\u001b[1;37mINFO\u001b[0m ] Plasma stratification:\n",
+ " (\u001B[1mbase.py\u001B[0m:350)\n",
+ "[\u001B[1mtardis.simulation.base\u001B[0m][\u001B[1;37mINFO\u001B[0m ] t_inner 9978.058 K -- next t_inner 11365.561 K (\u001B[1mbase.py\u001B[0m:352)\n",
+ "[\u001B[1mtardis.simulation.base\u001B[0m][\u001B[1;37mINFO\u001B[0m ] Starting iteration 6/20 (\u001B[1mbase.py\u001B[0m:268)\n",
+ "[\u001B[1mtardis.simulation.base\u001B[0m][\u001B[1;37mINFO\u001B[0m ] Luminosity emitted = 1.36136e+43 erg / s Luminosity absorbed = 4.54590e+42 erg / s Luminosity requested = 1.05928e+43 erg / s (\u001B[1mbase.py\u001B[0m:359)\n",
+ "[\u001B[1mtardis.simulation.base\u001B[0m][\u001B[1;37mINFO\u001B[0m ] Plasma stratification:\n",
"\t t_rad next_t_rad w next_w\n",
"\tShell \n",
"\t0 10556.913414 11562.006340 0.440229 0.509603\n",
@@ -141,11 +141,11 @@
"\t10 10713.104080 11482.742597 0.099268 0.124721\n",
"\t15 10399.079825 11124.799749 0.073482 0.093597\n",
"\n",
- " (\u001b[1mbase.py\u001b[0m:350)\n",
- "[\u001b[1mtardis.simulation.base\u001b[0m][\u001b[1;37mINFO\u001b[0m ] t_inner 11365.561 K -- next t_inner 10025.564 K (\u001b[1mbase.py\u001b[0m:352)\n",
- "[\u001b[1mtardis.simulation.base\u001b[0m][\u001b[1;37mINFO\u001b[0m ] Starting iteration 7/20 (\u001b[1mbase.py\u001b[0m:268)\n",
- "[\u001b[1mtardis.simulation.base\u001b[0m][\u001b[1;37mINFO\u001b[0m ] Luminosity emitted = 8.33278e+42 erg / s Luminosity absorbed = 2.66283e+42 erg / s Luminosity requested = 1.05928e+43 erg / s (\u001b[1mbase.py\u001b[0m:359)\n",
- "[\u001b[1mtardis.simulation.base\u001b[0m][\u001b[1;37mINFO\u001b[0m ] Plasma stratification:\n",
+ " (\u001B[1mbase.py\u001B[0m:350)\n",
+ "[\u001B[1mtardis.simulation.base\u001B[0m][\u001B[1;37mINFO\u001B[0m ] t_inner 11365.561 K -- next t_inner 10025.564 K (\u001B[1mbase.py\u001B[0m:352)\n",
+ "[\u001B[1mtardis.simulation.base\u001B[0m][\u001B[1;37mINFO\u001B[0m ] Starting iteration 7/20 (\u001B[1mbase.py\u001B[0m:268)\n",
+ "[\u001B[1mtardis.simulation.base\u001B[0m][\u001B[1;37mINFO\u001B[0m ] Luminosity emitted = 8.33278e+42 erg / s Luminosity absorbed = 2.66283e+42 erg / s Luminosity requested = 1.05928e+43 erg / s (\u001B[1mbase.py\u001B[0m:359)\n",
+ "[\u001B[1mtardis.simulation.base\u001B[0m][\u001B[1;37mINFO\u001B[0m ] Plasma stratification:\n",
"\t t_rad next_t_rad w next_w\n",
"\tShell \n",
"\t0 11562.006340 10655.549804 0.509603 0.430187\n",
@@ -153,11 +153,11 @@
"\t10 11482.742597 10926.058943 0.124721 0.094642\n",
"\t15 11124.799749 10477.041314 0.093597 0.072578\n",
"\n",
- " (\u001b[1mbase.py\u001b[0m:350)\n",
- "[\u001b[1mtardis.simulation.base\u001b[0m][\u001b[1;37mINFO\u001b[0m ] t_inner 10025.564 K -- next t_inner 11303.643 K (\u001b[1mbase.py\u001b[0m:352)\n",
- "[\u001b[1mtardis.simulation.base\u001b[0m][\u001b[1;37mINFO\u001b[0m ] Starting iteration 8/20 (\u001b[1mbase.py\u001b[0m:268)\n",
- "[\u001b[1mtardis.simulation.base\u001b[0m][\u001b[1;37mINFO\u001b[0m ] Luminosity emitted = 1.34650e+43 erg / s Luminosity absorbed = 4.30670e+42 erg / s Luminosity requested = 1.05928e+43 erg / s (\u001b[1mbase.py\u001b[0m:359)\n",
- "[\u001b[1mtardis.simulation.base\u001b[0m][\u001b[1;37mINFO\u001b[0m ] Plasma stratification:\n",
+ " (\u001B[1mbase.py\u001B[0m:350)\n",
+ "[\u001B[1mtardis.simulation.base\u001B[0m][\u001B[1;37mINFO\u001B[0m ] t_inner 10025.564 K -- next t_inner 11303.643 K (\u001B[1mbase.py\u001B[0m:352)\n",
+ "[\u001B[1mtardis.simulation.base\u001B[0m][\u001B[1;37mINFO\u001B[0m ] Starting iteration 8/20 (\u001B[1mbase.py\u001B[0m:268)\n",
+ "[\u001B[1mtardis.simulation.base\u001B[0m][\u001B[1;37mINFO\u001B[0m ] Luminosity emitted = 1.34650e+43 erg / s Luminosity absorbed = 4.30670e+42 erg / s Luminosity requested = 1.05928e+43 erg / s (\u001B[1mbase.py\u001B[0m:359)\n",
+ "[\u001B[1mtardis.simulation.base\u001B[0m][\u001B[1;37mINFO\u001B[0m ] Plasma stratification:\n",
"\t t_rad next_t_rad w next_w\n",
"\tShell \n",
"\t0 10655.549804 11572.119736 0.430187 0.496558\n",
@@ -165,11 +165,11 @@
"\t10 10926.058943 11482.609682 0.094642 0.124382\n",
"\t15 10477.041314 11098.080451 0.072578 0.093537\n",
"\n",
- " (\u001b[1mbase.py\u001b[0m:350)\n",
- "[\u001b[1mtardis.simulation.base\u001b[0m][\u001b[1;37mINFO\u001b[0m ] t_inner 11303.643 K -- next t_inner 10025.810 K (\u001b[1mbase.py\u001b[0m:352)\n",
- "[\u001b[1mtardis.simulation.base\u001b[0m][\u001b[1;37mINFO\u001b[0m ] Starting iteration 9/20 (\u001b[1mbase.py\u001b[0m:268)\n",
- "[\u001b[1mtardis.simulation.base\u001b[0m][\u001b[1;37mINFO\u001b[0m ] Luminosity emitted = 8.36983e+42 erg / s Luminosity absorbed = 2.63049e+42 erg / s Luminosity requested = 1.05928e+43 erg / s (\u001b[1mbase.py\u001b[0m:359)\n",
- "[\u001b[1mtardis.simulation.base\u001b[0m][\u001b[1;37mINFO\u001b[0m ] Plasma stratification:\n",
+ " (\u001B[1mbase.py\u001B[0m:350)\n",
+ "[\u001B[1mtardis.simulation.base\u001B[0m][\u001B[1;37mINFO\u001B[0m ] t_inner 11303.643 K -- next t_inner 10025.810 K (\u001B[1mbase.py\u001B[0m:352)\n",
+ "[\u001B[1mtardis.simulation.base\u001B[0m][\u001B[1;37mINFO\u001B[0m ] Starting iteration 9/20 (\u001B[1mbase.py\u001B[0m:268)\n",
+ "[\u001B[1mtardis.simulation.base\u001B[0m][\u001B[1;37mINFO\u001B[0m ] Luminosity emitted = 8.36983e+42 erg / s Luminosity absorbed = 2.63049e+42 erg / s Luminosity requested = 1.05928e+43 erg / s (\u001B[1mbase.py\u001B[0m:359)\n",
+ "[\u001B[1mtardis.simulation.base\u001B[0m][\u001B[1;37mINFO\u001B[0m ] Plasma stratification:\n",
"\t t_rad next_t_rad w next_w\n",
"\tShell \n",
"\t0 11572.119736 10590.775937 0.496558 0.439574\n",
@@ -177,17 +177,17 @@
"\t10 11482.609682 10761.665022 0.124382 0.099840\n",
"\t15 11098.080451 10436.629671 0.093537 0.074676\n",
"\n",
- " (\u001b[1mbase.py\u001b[0m:350)\n"
+ " (\u001B[1mbase.py\u001B[0m:350)\n"
]
},
{
"name": "stdout",
"output_type": "stream",
"text": [
- "[\u001b[1mtardis.simulation.base\u001b[0m][\u001b[1;37mINFO\u001b[0m ] t_inner 10025.810 K -- next t_inner 11278.874 K (\u001b[1mbase.py\u001b[0m:352)\n",
- "[\u001b[1mtardis.simulation.base\u001b[0m][\u001b[1;37mINFO\u001b[0m ] Starting iteration 10/20 (\u001b[1mbase.py\u001b[0m:268)\n",
- "[\u001b[1mtardis.simulation.base\u001b[0m][\u001b[1;37mINFO\u001b[0m ] Luminosity emitted = 1.32624e+43 erg / s Luminosity absorbed = 4.34986e+42 erg / s Luminosity requested = 1.05928e+43 erg / s (\u001b[1mbase.py\u001b[0m:359)\n",
- "[\u001b[1mtardis.simulation.base\u001b[0m][\u001b[1;37mINFO\u001b[0m ] Plasma stratification:\n",
+ "[\u001B[1mtardis.simulation.base\u001B[0m][\u001B[1;37mINFO\u001B[0m ] t_inner 10025.810 K -- next t_inner 11278.874 K (\u001B[1mbase.py\u001B[0m:352)\n",
+ "[\u001B[1mtardis.simulation.base\u001B[0m][\u001B[1;37mINFO\u001B[0m ] Starting iteration 10/20 (\u001B[1mbase.py\u001B[0m:268)\n",
+ "[\u001B[1mtardis.simulation.base\u001B[0m][\u001B[1;37mINFO\u001B[0m ] Luminosity emitted = 1.32624e+43 erg / s Luminosity absorbed = 4.34986e+42 erg / s Luminosity requested = 1.05928e+43 erg / s (\u001B[1mbase.py\u001B[0m:359)\n",
+ "[\u001B[1mtardis.simulation.base\u001B[0m][\u001B[1;37mINFO\u001B[0m ] Plasma stratification:\n",
"\t t_rad next_t_rad w next_w\n",
"\tShell \n",
"\t0 10590.775937 11489.769556 0.439574 0.511403\n",
@@ -195,11 +195,11 @@
"\t10 10761.665022 11527.732208 0.099840 0.120106\n",
"\t15 10436.629671 11111.114390 0.074676 0.091713\n",
"\n",
- " (\u001b[1mbase.py\u001b[0m:350)\n",
- "[\u001b[1mtardis.simulation.base\u001b[0m][\u001b[1;37mINFO\u001b[0m ] t_inner 11278.874 K -- next t_inner 10079.967 K (\u001b[1mbase.py\u001b[0m:352)\n",
- "[\u001b[1mtardis.simulation.base\u001b[0m][\u001b[1;37mINFO\u001b[0m ] Starting iteration 11/20 (\u001b[1mbase.py\u001b[0m:268)\n",
- "[\u001b[1mtardis.simulation.base\u001b[0m][\u001b[1;37mINFO\u001b[0m ] Luminosity emitted = 8.51915e+42 erg / s Luminosity absorbed = 2.72009e+42 erg / s Luminosity requested = 1.05928e+43 erg / s (\u001b[1mbase.py\u001b[0m:359)\n",
- "[\u001b[1mtardis.simulation.base\u001b[0m][\u001b[1;37mINFO\u001b[0m ] Plasma stratification:\n",
+ " (\u001B[1mbase.py\u001B[0m:350)\n",
+ "[\u001B[1mtardis.simulation.base\u001B[0m][\u001B[1;37mINFO\u001B[0m ] t_inner 11278.874 K -- next t_inner 10079.967 K (\u001B[1mbase.py\u001B[0m:352)\n",
+ "[\u001B[1mtardis.simulation.base\u001B[0m][\u001B[1;37mINFO\u001B[0m ] Starting iteration 11/20 (\u001B[1mbase.py\u001B[0m:268)\n",
+ "[\u001B[1mtardis.simulation.base\u001B[0m][\u001B[1;37mINFO\u001B[0m ] Luminosity emitted = 8.51915e+42 erg / s Luminosity absorbed = 2.72009e+42 erg / s Luminosity requested = 1.05928e+43 erg / s (\u001B[1mbase.py\u001B[0m:359)\n",
+ "[\u001B[1mtardis.simulation.base\u001B[0m][\u001B[1;37mINFO\u001B[0m ] Plasma stratification:\n",
"\t t_rad next_t_rad w next_w\n",
"\tShell \n",
"\t0 11489.769556 10664.234475 0.511403 0.437272\n",
@@ -207,11 +207,11 @@
"\t10 11527.732208 10885.771059 0.120106 0.096973\n",
"\t15 11111.114390 10484.177251 0.091713 0.074261\n",
"\n",
- " (\u001b[1mbase.py\u001b[0m:350)\n",
- "[\u001b[1mtardis.simulation.base\u001b[0m][\u001b[1;37mINFO\u001b[0m ] t_inner 10079.967 K -- next t_inner 11239.980 K (\u001b[1mbase.py\u001b[0m:352)\n",
- "[\u001b[1mtardis.simulation.base\u001b[0m][\u001b[1;37mINFO\u001b[0m ] Starting iteration 12/20 (\u001b[1mbase.py\u001b[0m:268)\n",
- "[\u001b[1mtardis.simulation.base\u001b[0m][\u001b[1;37mINFO\u001b[0m ] Luminosity emitted = 1.30886e+43 erg / s Luminosity absorbed = 4.28617e+42 erg / s Luminosity requested = 1.05928e+43 erg / s (\u001b[1mbase.py\u001b[0m:359)\n",
- "[\u001b[1mtardis.simulation.base\u001b[0m][\u001b[1;37mINFO\u001b[0m ] Plasma stratification:\n",
+ " (\u001B[1mbase.py\u001B[0m:350)\n",
+ "[\u001B[1mtardis.simulation.base\u001B[0m][\u001B[1;37mINFO\u001B[0m ] t_inner 10079.967 K -- next t_inner 11239.980 K (\u001B[1mbase.py\u001B[0m:352)\n",
+ "[\u001B[1mtardis.simulation.base\u001B[0m][\u001B[1;37mINFO\u001B[0m ] Starting iteration 12/20 (\u001B[1mbase.py\u001B[0m:268)\n",
+ "[\u001B[1mtardis.simulation.base\u001B[0m][\u001B[1;37mINFO\u001B[0m ] Luminosity emitted = 1.30886e+43 erg / s Luminosity absorbed = 4.28617e+42 erg / s Luminosity requested = 1.05928e+43 erg / s (\u001B[1mbase.py\u001B[0m:359)\n",
+ "[\u001B[1mtardis.simulation.base\u001B[0m][\u001B[1;37mINFO\u001B[0m ] Plasma stratification:\n",
"\t t_rad next_t_rad w next_w\n",
"\tShell \n",
"\t0 10664.234475 11510.842068 0.437272 0.495944\n",
@@ -219,11 +219,11 @@
"\t10 10885.771059 11479.636914 0.096973 0.120067\n",
"\t15 10484.177251 11117.963837 0.074261 0.090628\n",
"\n",
- " (\u001b[1mbase.py\u001b[0m:350)\n",
- "[\u001b[1mtardis.simulation.base\u001b[0m][\u001b[1;37mINFO\u001b[0m ] t_inner 11239.980 K -- next t_inner 10111.668 K (\u001b[1mbase.py\u001b[0m:352)\n",
- "[\u001b[1mtardis.simulation.base\u001b[0m][\u001b[1;37mINFO\u001b[0m ] Starting iteration 13/20 (\u001b[1mbase.py\u001b[0m:268)\n",
- "[\u001b[1mtardis.simulation.base\u001b[0m][\u001b[1;37mINFO\u001b[0m ] Luminosity emitted = 8.65047e+42 erg / s Luminosity absorbed = 2.72874e+42 erg / s Luminosity requested = 1.05928e+43 erg / s (\u001b[1mbase.py\u001b[0m:359)\n",
- "[\u001b[1mtardis.simulation.base\u001b[0m][\u001b[1;37mINFO\u001b[0m ] Plasma stratification:\n",
+ " (\u001B[1mbase.py\u001B[0m:350)\n",
+ "[\u001B[1mtardis.simulation.base\u001B[0m][\u001B[1;37mINFO\u001B[0m ] t_inner 11239.980 K -- next t_inner 10111.668 K (\u001B[1mbase.py\u001B[0m:352)\n",
+ "[\u001B[1mtardis.simulation.base\u001B[0m][\u001B[1;37mINFO\u001B[0m ] Starting iteration 13/20 (\u001B[1mbase.py\u001B[0m:268)\n",
+ "[\u001B[1mtardis.simulation.base\u001B[0m][\u001B[1;37mINFO\u001B[0m ] Luminosity emitted = 8.65047e+42 erg / s Luminosity absorbed = 2.72874e+42 erg / s Luminosity requested = 1.05928e+43 erg / s (\u001B[1mbase.py\u001B[0m:359)\n",
+ "[\u001B[1mtardis.simulation.base\u001B[0m][\u001B[1;37mINFO\u001B[0m ] Plasma stratification:\n",
"\t t_rad next_t_rad w next_w\n",
"\tShell \n",
"\t0 11510.842068 10636.025493 0.495944 0.446635\n",
@@ -231,11 +231,11 @@
"\t10 11479.636914 10916.188023 0.120067 0.097843\n",
"\t15 11117.963837 10431.720831 0.090628 0.077032\n",
"\n",
- " (\u001b[1mbase.py\u001b[0m:350)\n",
- "[\u001b[1mtardis.simulation.base\u001b[0m][\u001b[1;37mINFO\u001b[0m ] t_inner 10111.668 K -- next t_inner 11189.420 K (\u001b[1mbase.py\u001b[0m:352)\n",
- "[\u001b[1mtardis.simulation.base\u001b[0m][\u001b[1;37mINFO\u001b[0m ] Starting iteration 14/20 (\u001b[1mbase.py\u001b[0m:268)\n",
- "[\u001b[1mtardis.simulation.base\u001b[0m][\u001b[1;37mINFO\u001b[0m ] Luminosity emitted = 1.28712e+43 erg / s Luminosity absorbed = 4.19242e+42 erg / s Luminosity requested = 1.05928e+43 erg / s (\u001b[1mbase.py\u001b[0m:359)\n",
- "[\u001b[1mtardis.simulation.base\u001b[0m][\u001b[1;37mINFO\u001b[0m ] Plasma stratification:\n",
+ " (\u001B[1mbase.py\u001B[0m:350)\n",
+ "[\u001B[1mtardis.simulation.base\u001B[0m][\u001B[1;37mINFO\u001B[0m ] t_inner 10111.668 K -- next t_inner 11189.420 K (\u001B[1mbase.py\u001B[0m:352)\n",
+ "[\u001B[1mtardis.simulation.base\u001B[0m][\u001B[1;37mINFO\u001B[0m ] Starting iteration 14/20 (\u001B[1mbase.py\u001B[0m:268)\n",
+ "[\u001B[1mtardis.simulation.base\u001B[0m][\u001B[1;37mINFO\u001B[0m ] Luminosity emitted = 1.28712e+43 erg / s Luminosity absorbed = 4.19242e+42 erg / s Luminosity requested = 1.05928e+43 erg / s (\u001B[1mbase.py\u001B[0m:359)\n",
+ "[\u001B[1mtardis.simulation.base\u001B[0m][\u001B[1;37mINFO\u001B[0m ] Plasma stratification:\n",
"\t t_rad next_t_rad w next_w\n",
"\tShell \n",
"\t0 10636.025493 11423.118214 0.446635 0.503706\n",
@@ -243,11 +243,11 @@
"\t10 10916.188023 11389.994295 0.097843 0.121114\n",
"\t15 10431.720831 11029.450833 0.077032 0.091350\n",
"\n",
- " (\u001b[1mbase.py\u001b[0m:350)\n",
- "[\u001b[1mtardis.simulation.base\u001b[0m][\u001b[1;37mINFO\u001b[0m ] t_inner 11189.420 K -- next t_inner 10150.866 K (\u001b[1mbase.py\u001b[0m:352)\n",
- "[\u001b[1mtardis.simulation.base\u001b[0m][\u001b[1;37mINFO\u001b[0m ] Starting iteration 15/20 (\u001b[1mbase.py\u001b[0m:268)\n",
- "[\u001b[1mtardis.simulation.base\u001b[0m][\u001b[1;37mINFO\u001b[0m ] Luminosity emitted = 8.76501e+42 erg / s Luminosity absorbed = 2.79433e+42 erg / s Luminosity requested = 1.05928e+43 erg / s (\u001b[1mbase.py\u001b[0m:359)\n",
- "[\u001b[1mtardis.simulation.base\u001b[0m][\u001b[1;37mINFO\u001b[0m ] Plasma stratification:\n",
+ " (\u001B[1mbase.py\u001B[0m:350)\n",
+ "[\u001B[1mtardis.simulation.base\u001B[0m][\u001B[1;37mINFO\u001B[0m ] t_inner 11189.420 K -- next t_inner 10150.866 K (\u001B[1mbase.py\u001B[0m:352)\n",
+ "[\u001B[1mtardis.simulation.base\u001B[0m][\u001B[1;37mINFO\u001B[0m ] Starting iteration 15/20 (\u001B[1mbase.py\u001B[0m:268)\n",
+ "[\u001B[1mtardis.simulation.base\u001B[0m][\u001B[1;37mINFO\u001B[0m ] Luminosity emitted = 8.76501e+42 erg / s Luminosity absorbed = 2.79433e+42 erg / s Luminosity requested = 1.05928e+43 erg / s (\u001B[1mbase.py\u001B[0m:359)\n",
+ "[\u001B[1mtardis.simulation.base\u001B[0m][\u001B[1;37mINFO\u001B[0m ] Plasma stratification:\n",
"\t t_rad next_t_rad w next_w\n",
"\tShell \n",
"\t0 11423.118214 10634.831735 0.503706 0.452948\n",
@@ -255,11 +255,11 @@
"\t10 11389.994295 10831.887277 0.121114 0.101805\n",
"\t15 11029.450833 10396.372864 0.091350 0.078776\n",
"\n",
- " (\u001b[1mbase.py\u001b[0m:350)\n",
- "[\u001b[1mtardis.simulation.base\u001b[0m][\u001b[1;37mINFO\u001b[0m ] t_inner 10150.866 K -- next t_inner 11159.164 K (\u001b[1mbase.py\u001b[0m:352)\n",
- "[\u001b[1mtardis.simulation.base\u001b[0m][\u001b[1;37mINFO\u001b[0m ] Starting iteration 16/20 (\u001b[1mbase.py\u001b[0m:268)\n",
- "[\u001b[1mtardis.simulation.base\u001b[0m][\u001b[1;37mINFO\u001b[0m ] Luminosity emitted = 1.27462e+43 erg / s Luminosity absorbed = 4.13373e+42 erg / s Luminosity requested = 1.05928e+43 erg / s (\u001b[1mbase.py\u001b[0m:359)\n",
- "[\u001b[1mtardis.simulation.base\u001b[0m][\u001b[1;37mINFO\u001b[0m ] Plasma stratification:\n",
+ " (\u001B[1mbase.py\u001B[0m:350)\n",
+ "[\u001B[1mtardis.simulation.base\u001B[0m][\u001B[1;37mINFO\u001B[0m ] t_inner 10150.866 K -- next t_inner 11159.164 K (\u001B[1mbase.py\u001B[0m:352)\n",
+ "[\u001B[1mtardis.simulation.base\u001B[0m][\u001B[1;37mINFO\u001B[0m ] Starting iteration 16/20 (\u001B[1mbase.py\u001B[0m:268)\n",
+ "[\u001B[1mtardis.simulation.base\u001B[0m][\u001B[1;37mINFO\u001B[0m ] Luminosity emitted = 1.27462e+43 erg / s Luminosity absorbed = 4.13373e+42 erg / s Luminosity requested = 1.05928e+43 erg / s (\u001B[1mbase.py\u001B[0m:359)\n",
+ "[\u001B[1mtardis.simulation.base\u001B[0m][\u001B[1;37mINFO\u001B[0m ] Plasma stratification:\n",
"\t t_rad next_t_rad w next_w\n",
"\tShell \n",
"\t0 10634.831735 11415.925493 0.452948 0.501153\n",
@@ -267,11 +267,11 @@
"\t10 10831.887277 11397.519913 0.101805 0.120134\n",
"\t15 10396.372864 11045.200458 0.078776 0.090180\n",
"\n",
- " (\u001b[1mbase.py\u001b[0m:350)\n",
- "[\u001b[1mtardis.simulation.base\u001b[0m][\u001b[1;37mINFO\u001b[0m ] t_inner 11159.164 K -- next t_inner 10172.913 K (\u001b[1mbase.py\u001b[0m:352)\n",
- "[\u001b[1mtardis.simulation.base\u001b[0m][\u001b[1;37mINFO\u001b[0m ] Starting iteration 17/20 (\u001b[1mbase.py\u001b[0m:268)\n",
- "[\u001b[1mtardis.simulation.base\u001b[0m][\u001b[1;37mINFO\u001b[0m ] Luminosity emitted = 8.86785e+42 erg / s Luminosity absorbed = 2.79094e+42 erg / s Luminosity requested = 1.05928e+43 erg / s (\u001b[1mbase.py\u001b[0m:359)\n",
- "[\u001b[1mtardis.simulation.base\u001b[0m][\u001b[1;37mINFO\u001b[0m ] Plasma stratification:\n",
+ " (\u001B[1mbase.py\u001B[0m:350)\n",
+ "[\u001B[1mtardis.simulation.base\u001B[0m][\u001B[1;37mINFO\u001B[0m ] t_inner 11159.164 K -- next t_inner 10172.913 K (\u001B[1mbase.py\u001B[0m:352)\n",
+ "[\u001B[1mtardis.simulation.base\u001B[0m][\u001B[1;37mINFO\u001B[0m ] Starting iteration 17/20 (\u001B[1mbase.py\u001B[0m:268)\n",
+ "[\u001B[1mtardis.simulation.base\u001B[0m][\u001B[1;37mINFO\u001B[0m ] Luminosity emitted = 8.86785e+42 erg / s Luminosity absorbed = 2.79094e+42 erg / s Luminosity requested = 1.05928e+43 erg / s (\u001B[1mbase.py\u001B[0m:359)\n",
+ "[\u001B[1mtardis.simulation.base\u001B[0m][\u001B[1;37mINFO\u001B[0m ] Plasma stratification:\n",
"\t t_rad next_t_rad w next_w\n",
"\tShell \n",
"\t0 11415.925493 10678.510651 0.501153 0.453127\n",
@@ -279,11 +279,11 @@
"\t10 11397.519913 10907.112682 0.120134 0.099725\n",
"\t15 11045.200458 10508.816973 0.090180 0.076667\n",
"\n",
- " (\u001b[1mbase.py\u001b[0m:350)\n",
- "[\u001b[1mtardis.simulation.base\u001b[0m][\u001b[1;37mINFO\u001b[0m ] t_inner 10172.913 K -- next t_inner 11118.359 K (\u001b[1mbase.py\u001b[0m:352)\n",
- "[\u001b[1mtardis.simulation.base\u001b[0m][\u001b[1;37mINFO\u001b[0m ] Starting iteration 18/20 (\u001b[1mbase.py\u001b[0m:268)\n",
- "[\u001b[1mtardis.simulation.base\u001b[0m][\u001b[1;37mINFO\u001b[0m ] Luminosity emitted = 1.24749e+43 erg / s Luminosity absorbed = 4.15445e+42 erg / s Luminosity requested = 1.05928e+43 erg / s (\u001b[1mbase.py\u001b[0m:359)\n",
- "[\u001b[1mtardis.simulation.base\u001b[0m][\u001b[1;37mINFO\u001b[0m ] Plasma stratification:\n",
+ " (\u001B[1mbase.py\u001B[0m:350)\n",
+ "[\u001B[1mtardis.simulation.base\u001B[0m][\u001B[1;37mINFO\u001B[0m ] t_inner 10172.913 K -- next t_inner 11118.359 K (\u001B[1mbase.py\u001B[0m:352)\n",
+ "[\u001B[1mtardis.simulation.base\u001B[0m][\u001B[1;37mINFO\u001B[0m ] Starting iteration 18/20 (\u001B[1mbase.py\u001B[0m:268)\n",
+ "[\u001B[1mtardis.simulation.base\u001B[0m][\u001B[1;37mINFO\u001B[0m ] Luminosity emitted = 1.24749e+43 erg / s Luminosity absorbed = 4.15445e+42 erg / s Luminosity requested = 1.05928e+43 erg / s (\u001B[1mbase.py\u001B[0m:359)\n",
+ "[\u001B[1mtardis.simulation.base\u001B[0m][\u001B[1;37mINFO\u001B[0m ] Plasma stratification:\n",
"\t t_rad next_t_rad w next_w\n",
"\tShell \n",
"\t0 10678.510651 11482.446420 0.453127 0.481917\n",
@@ -291,11 +291,11 @@
"\t10 10907.112682 11472.013555 0.099725 0.115208\n",
"\t15 10508.816973 10997.309982 0.076667 0.089730\n",
"\n",
- " (\u001b[1mbase.py\u001b[0m:350)\n",
- "[\u001b[1mtardis.simulation.base\u001b[0m][\u001b[1;37mINFO\u001b[0m ] t_inner 11118.359 K -- next t_inner 10245.337 K (\u001b[1mbase.py\u001b[0m:352)\n",
- "[\u001b[1mtardis.simulation.base\u001b[0m][\u001b[1;37mINFO\u001b[0m ] Starting iteration 19/20 (\u001b[1mbase.py\u001b[0m:268)\n",
- "[\u001b[1mtardis.simulation.base\u001b[0m][\u001b[1;37mINFO\u001b[0m ] Luminosity emitted = 9.09476e+42 erg / s Luminosity absorbed = 2.89713e+42 erg / s Luminosity requested = 1.05928e+43 erg / s (\u001b[1mbase.py\u001b[0m:359)\n",
- "[\u001b[1mtardis.simulation.base\u001b[0m][\u001b[1;37mINFO\u001b[0m ] Plasma stratification:\n",
+ " (\u001B[1mbase.py\u001B[0m:350)\n",
+ "[\u001B[1mtardis.simulation.base\u001B[0m][\u001B[1;37mINFO\u001B[0m ] t_inner 11118.359 K -- next t_inner 10245.337 K (\u001B[1mbase.py\u001B[0m:352)\n",
+ "[\u001B[1mtardis.simulation.base\u001B[0m][\u001B[1;37mINFO\u001B[0m ] Starting iteration 19/20 (\u001B[1mbase.py\u001B[0m:268)\n",
+ "[\u001B[1mtardis.simulation.base\u001B[0m][\u001B[1;37mINFO\u001B[0m ] Luminosity emitted = 9.09476e+42 erg / s Luminosity absorbed = 2.89713e+42 erg / s Luminosity requested = 1.05928e+43 erg / s (\u001B[1mbase.py\u001B[0m:359)\n",
+ "[\u001B[1mtardis.simulation.base\u001B[0m][\u001B[1;37mINFO\u001B[0m ] Plasma stratification:\n",
"\t t_rad next_t_rad w next_w\n",
"\tShell \n",
"\t0 11482.446420 10834.729769 0.481917 0.438322\n",
@@ -303,17 +303,17 @@
"\t10 11472.013555 10996.421420 0.115208 0.099677\n",
"\t15 10997.309982 10625.479432 0.089730 0.075531\n",
"\n",
- " (\u001b[1mbase.py\u001b[0m:350)\n"
+ " (\u001B[1mbase.py\u001B[0m:350)\n"
]
},
{
"name": "stdout",
"output_type": "stream",
"text": [
- "[\u001b[1mtardis.simulation.base\u001b[0m][\u001b[1;37mINFO\u001b[0m ] t_inner 10245.337 K -- next t_inner 11056.949 K (\u001b[1mbase.py\u001b[0m:352)\n",
- "[\u001b[1mtardis.simulation.base\u001b[0m][\u001b[1;37mINFO\u001b[0m ] Starting iteration 20/20 (\u001b[1mbase.py\u001b[0m:268)\n",
- "[\u001b[1mtardis.simulation.base\u001b[0m][\u001b[1;37mINFO\u001b[0m ] Luminosity emitted = 1.22623e+43 erg / s Luminosity absorbed = 4.00603e+42 erg / s Luminosity requested = 1.05928e+43 erg / s (\u001b[1mbase.py\u001b[0m:359)\n",
- "[\u001b[1mtardis.simulation.base\u001b[0m][\u001b[1;37mINFO\u001b[0m ] Simulation finished in 20 iterations and took 23.27 s (\u001b[1mbase.py\u001b[0m:308)\n"
+ "[\u001B[1mtardis.simulation.base\u001B[0m][\u001B[1;37mINFO\u001B[0m ] t_inner 10245.337 K -- next t_inner 11056.949 K (\u001B[1mbase.py\u001B[0m:352)\n",
+ "[\u001B[1mtardis.simulation.base\u001B[0m][\u001B[1;37mINFO\u001B[0m ] Starting iteration 20/20 (\u001B[1mbase.py\u001B[0m:268)\n",
+ "[\u001B[1mtardis.simulation.base\u001B[0m][\u001B[1;37mINFO\u001B[0m ] Luminosity emitted = 1.22623e+43 erg / s Luminosity absorbed = 4.00603e+42 erg / s Luminosity requested = 1.05928e+43 erg / s (\u001B[1mbase.py\u001B[0m:359)\n",
+ "[\u001B[1mtardis.simulation.base\u001B[0m][\u001B[1;37mINFO\u001B[0m ] Simulation finished in 20 iterations and took 23.27 s (\u001B[1mbase.py\u001B[0m:308)\n"
]
}
],
@@ -4733,4 +4733,4 @@
},
"nbformat": 4,
"nbformat_minor": 4
-}
+}
\ No newline at end of file
diff --git a/docs/physics/plasma/helium_nlte.rst b/docs/physics/plasma/helium_nlte.rst
index 6f3ec0eaf4a..99267d6de20 100644
--- a/docs/physics/plasma/helium_nlte.rst
+++ b/docs/physics/plasma/helium_nlte.rst
@@ -1,17 +1,17 @@
Helium NLTE
============
-The `helium_treatment` setting in the Tardis config. file will accept one of three options:
+The `helium_treatment` setting in the TARDIS config. file will accept one of three options:
* `none`: The default setting. Populate helium in the same way as the other elements.
* `recomb-nlte`: Treats helium in NLTE using the analytical approximation outlined in an upcoming paper.
- * `numerical-nlte`: To be implemented. Will allow the use of a separate module (not distributed with Tardis) to perform helium NLTE calculations numerically.
+ * `numerical-nlte`: To be implemented. Will allow the use of a separate module (not distributed with TARDIS) to perform helium NLTE calculations numerically.
Recombination He NLTE
----------------------
Paper version:
-This section will summarise the equations used in the calculation of the helium state for the `recomb-NLTE` approximation in Tardis. A full physical justification for these equations will be provided in an upcoming paper. All of the level populations are given as a function of the He II ground state population (:math:`n_{2,1,0}`), and the values are then normalised using the helium number density to give the correct level number densities.
+This section will summarise the equations used in the calculation of the helium state for the `recomb-NLTE` approximation in TARDIS. A full physical justification for these equations will be provided in an upcoming paper. All of the level populations are given as a function of the He II ground state population (:math:`n_{2,1,0}`), and the values are then normalised using the helium number density to give the correct level number densities.
Symbols/Indexing:
* :math:`N_{i,j}`: Ion Number Density
@@ -40,7 +40,7 @@ Symbols/Indexing:
Code Version:
-In the Tardis plasma, some of these equations are re-written slightly to make use of existing property methods (e.g. `PhiSahaLTE`, `PhiSahaNebular`) often using the relation:
+In the TARDIS plasma, some of these equations are re-written slightly to make use of existing property methods (e.g. `PhiSahaLTE`, `PhiSahaNebular`) often using the relation:
.. math::
\frac{N_{i,j}}{Z_{i,j}} = \frac{n_{i,j,k}}{g_{i,j,k}}
@@ -48,4 +48,4 @@ In the Tardis plasma, some of these equations are re-written slightly to make us
Numerical He NLTE
------------------
-Another `helium_treatment` option offered by Tardis is `numerical-nlte`. The use of this plasma property requires an additional code that is the property of Stephan Hachinger (see arXiv:1201.1506) and is not distributed with Tardis. Tardis also requires a specific atomic datafile to use this module. This plasma option is included so that people who have access to and permission to use the necessary module may use it. Otherwise, the `recomb-NLTE` option provides a very accurate alternative approximation.
\ No newline at end of file
+Another `helium_treatment` option offered by TARDIS is `numerical-nlte`. The use of this plasma property requires an additional code that is the property of Stephan Hachinger (see arXiv:1201.1506) and is not distributed with TARDIS. TARDIS also requires a specific atomic datafile to use this module. This plasma option is included so that people who have access to and permission to use the necessary module may use it. Otherwise, the `recomb-NLTE` option provides a very accurate alternative approximation.
\ No newline at end of file
diff --git a/docs/physics/plasma/lte_plasma.rst b/docs/physics/plasma/lte_plasma.rst
index 8f773b45933..ff18efaf52a 100644
--- a/docs/physics/plasma/lte_plasma.rst
+++ b/docs/physics/plasma/lte_plasma.rst
@@ -2,12 +2,12 @@ LTE Plasma
----------
The `LTEPlasma` plasma class is the child of `BasePlasma` but is the first class that actually calculates plasma conditions.
-After running exactley through the same steps as `BasePlasma`, `LTEPlasma` will start calculating the `partition functions `_.
+After running exactly through the same steps as `BasePlasma`, `LTEPlasma` will start calculating the `partition functions `_.
.. math::
Z_{i, j} = \sum_{k=0}^{max (k)} g_k \times e^{-E_k / (k_\textrm{b} T)}
-, where Z is the partition function, g is the degeneracy factor, E the energy of the level and T the temperature of the radiation field.
+where Z is the partition function, g is the degeneracy factor, E the energy of the level and T the temperature of the radiation field.
The next step is to calculate the ionization balance using the `Saha ionization equation `_.
and then calculating the Number density of the ions (and an electron number density) in a second step.
@@ -30,11 +30,11 @@ In the second step (`LTEPlasma.calculate_ionization_balance`), we calculate in a
N_1 &= \frac{N(X)}{\alpha}
Initially, we set the electron density (:math:`N_e`) to the sum of all atom number densities. After having calculated the
-ion species number densities we recalculated the electron density by weighting the ion species number densities with their
+ion species number densities, we recalculate the electron density by weighting the ion species number densities with their
ion number (e.g. neutral ion number densities don't contribute at all to the electron number density, once ionized contribute with a
factor of 1, twice ionized contribute with a factor of two, ....).
-Finally we calculate the level populations (`LTEPlasma.calculate_level_populations`), by using the calculated ion species number densities:
+Finally, we calculate the level populations (`LTEPlasma.calculate_level_populations`) by using the calculated ion species number densities:
.. math::
N_{i, j, k} = \frac{g_k}{Z_{i, j}}\times N_{i, j} \times e^{-\beta_\textrm{rad} E_k}
diff --git a/docs/physics/plasma/macroatom.rst b/docs/physics/plasma/macroatom.rst
index c0272de8d18..9340fe79594 100644
--- a/docs/physics/plasma/macroatom.rst
+++ b/docs/physics/plasma/macroatom.rst
@@ -10,15 +10,15 @@ level and emitting a photon while doing this respectively (see Figure 1 in :cite
The macro atom is the most complex idea to implement as a data structure. The setup is done in `~tardisatomic`, but
we will nonetheless discuss it here (as `~tardisatomic` is even less documented than this one).
-For each level we look at the line list to see what transitions (upwards or downwards are possible). We create a two arrays,
-the first is a long one-dimensional array containing the probabilities. Each level contains a set of probabilities, The first
+For each level, we look at the line list to see what transitions (upwards or downwards are possible). We create a two arrays,
+the first is a long one-dimensional array containing the probabilities. Each level contains a set of probabilities. The first
part of each set contains the upwards probabilities (internal upward), the second part the downwards probabilities
(internal downward), and the last part is the downward and emission probability.
each set is stacked after the other one to make one long one dimensional `~numpy.ndarray`.
-The second array is for book-keeping it has exactly the length as levels (with an example for the Si II level 15):
+The second array is for book-keeping; it has exactly the length as levels (with an example for the Si II level 15):
+--------+------------------+------------+----------------+-----------------+
|Level ID| Probability index|N\ :sub:`up`| N\ :sub:`down` | N\ :sub:`total` |
@@ -41,7 +41,7 @@ where :math:`i` is the current level, :math:`\epsilon` is the energy of the leve
We ignore the probability to emit a k-packet as TARDIS only works with photon packets.
-Next we calculate the radidative
+Next we calculate the radiative
rates using equation 10 in :cite:`2003A&A...403..261L`.
.. math::
diff --git a/docs/physics/plasma/nebular_plasma.rst b/docs/physics/plasma/nebular_plasma.rst
index 51c729c26ed..1409d543dfc 100644
--- a/docs/physics/plasma/nebular_plasma.rst
+++ b/docs/physics/plasma/nebular_plasma.rst
@@ -5,7 +5,7 @@ The `NebularPlasma` class is a more complex description of the Plasma state than
(W) into account, which deals with the dilution of the radiation field due to geometric, line-blocking and other effects.
-The calculations follow the same steps as `LTEPlasma`, however the calculations are different and often take into account
+The calculations follow the same steps as `LTEPlasma`; however, the calculations are different and often take into account
if a particular level is :term:`meta-stable` or not.
`NebularPlasma` will start calculating the `partition functions `_.
@@ -14,13 +14,13 @@ if a particular level is :term:`meta-stable` or not.
Z_{i,j} = \underbrace{\sum_{k=0}^{max(k)_{i,j}} g_k \times e^{-E_k / (k_\textrm{b} T)}}_\textrm{metastable levels} +
\underbrace{W\times\sum_{k=0}^{max(k)_{i,j}} g_k \times e^{-E_k / (k_\textrm{b} T)}}_\textrm{non-metastable levels}
-, where Z is the partition function, g is the degeneracy factor, E the energy of the level, T the temperature of the radiation field
+where Z is the partition function, g is the degeneracy factor, E the energy of the level, T the temperature of the radiation field
and W the dilution factor.
-The next step is to calculate the ionization balance using the `Saha ionization equation `_.
-and then calculating the Number density of the ions (and an electron number density) in a second step.
+The next step is to calculate the ionization balance using the `Saha ionization equation `_
+and then calculate the number density of the ions (and an electron number density) in a second step.
In the first step, we calculate the ionization balance using the LTE approximation (:math:`\Phi_{i, j}(\textrm{LTE})`). Then we adjust the ionization balance using
-two factors :math:`\zeta` and :math:`\delta`.
+two factors: :math:`\zeta` and :math:`\delta`.
.. _calc_zeta_label:
@@ -36,7 +36,7 @@ Calculating Delta
:math:`\delta` is a radiation field correction factors which is calculated according to Mazzali & Lucy 1993 (:cite:`1993A&A...279..447M`; henceforth ML93)
-In ML93 the radiation field correction factor is denoted as :math:`\delta` and is calculated in Formula 15 & 20
+In ML93, the radiation field correction factor is denoted as :math:`\delta` and is calculated in Formula 15 & 20.
The radiation correction factor changes according to a ionization energy threshold :math:`\chi_\textrm{T}`
and the species ionization threshold (from the ground state) :math:`\chi_0`.
@@ -54,11 +54,11 @@ and the species ionization threshold (from the ground state) :math:`\chi_0`.
\frac{T_\textrm{e}}{b_1 W T_\textrm{R}} \exp(\frac{\chi_\textrm{T}}{k T_\textrm{R}} -
\frac{\chi_0}{k T_\textrm{e}}),
-where :math:`T_\textrm{R}` is the radiation field Temperature, :math:`T_\textrm{e}` is the electron temperature and W is the
+where :math:`T_\textrm{R}` is the radiation field temperature, :math:`T_\textrm{e}` is the electron temperature and W is the
dilution factor.
-Now we can calculate the ionization balance using equation 14 in :cite:`1993A&A...279..447M`:
+Now, we can calculate the ionization balance using equation 14 in :cite:`1993A&A...279..447M`:
.. math::
\Phi_{i,j} &= \frac{N_{i, j+1} n_e}{N_{i, j}} \\
@@ -69,7 +69,7 @@ Now we can calculate the ionization balance using equation 14 in :cite:`1993A&A.
In the last step, we calculate the ion number densities according using the methods in :class:`LTEPlasma`
-Finally we calculate the level populations (:func:`NebularPlasma.calculate_level_populations`),
+Finally, we calculate the level populations (:func:`NebularPlasma.calculate_level_populations`),
by using the calculated ion species number densities:
.. math::
diff --git a/docs/physics/plasma/nlte.rst b/docs/physics/plasma/nlte.rst
index 9a2e76a37ea..349bc3734e0 100644
--- a/docs/physics/plasma/nlte.rst
+++ b/docs/physics/plasma/nlte.rst
@@ -30,7 +30,7 @@ Next, we calculate the rate of change of a level by adding up all outgoing and a
\frac{dn_j}{dt} = \underbrace{\sum_{i \ne j} r_{ij}}_\textrm{incoming rate} -
\underbrace{\sum_{i \ne j} r_{ji}}_\textrm{outgoing rate}
-In a statistical equilibrium all incoming rates and outgoing rates add up to 0 (:math:`\frac{dn_j}{dt}=0`). We use this to
+In a statistical equilibrium, all incoming rates and outgoing rates add up to 0 (:math:`\frac{dn_j}{dt}=0`). We use this to
calculate the level populations using the rate coefficients (:math:`r_ij, r_ji`).
@@ -63,7 +63,7 @@ calculate the level populations using the rate coefficients (:math:`r_ij, r_ji`)
\right)
-with the additional constrained that all the level number populations need to add up to the current ion population $N$ we change this to
+with the additional constraint that all the level number populations need to add up to the current ion population :math:`N`, we change this to
.. math::
@@ -98,7 +98,7 @@ with the additional constrained that all the level number populations need to ad
-For a three level atom we have:
+For a three-level atom we have:
.. math::
@@ -137,8 +137,7 @@ which can be written in matrix from:
\end{matrix}
\right)
-To solve for the level populations we need an additional constraint: :math:`n_1 + n_2 + n_3 = N`. By setting :math:`N = 1`:
-we can get the relative rates:
+To solve for the level populations, we need an additional constraint: :math:`n_1 + n_2 + n_3 = N`. By setting :math:`N = 1`, we can get the relative rates:
.. math::
@@ -164,7 +163,7 @@ we can get the relative rates:
\right)
-Now we go back and look at the rate coefficients used for a level population - as an example :math:`\frac{dn_2}{dt}`:
+Now we go back and look at the rate coefficients used for a level population --- as an example :math:`\frac{dn_2}{dt}`:
.. math::
@@ -173,13 +172,16 @@ Now we go back and look at the rate coefficients used for a level population - a
- n_2 B_{23} \bar{J}_{23} - n_2 C_{23} n_e + n_3 A_{32} + n_3 B_{32} \bar{J}_{32} + n_3 C_{32} n_e,\\
+ n_3 A_{32} + n_3 C_{32} n_e,
-Next we will group the stimulated emission and stimulated absorption terms as we can assume :math:`\bar{J_{12}} = \bar{J_{21}}`:
+Next, we will group the stimulated emission and stimulated absorption terms, as we can assume :math:`\bar{J_{12}} = \bar{J_{21}}`:
.. math::
- \frac{dn_2}{dt} &= n_1 (B_{12} \bar{J}_{12} \underbrace{(1 - \frac{n_2}{n_1}\frac{B_{21}}{B_{12}})}_\textrm{stimulated emission term} + C_{12} n_e)
- - n_2 (A_{21} + C_{23} n_e + n_2 B_{23} \bar{J}_{23} \underbrace{(1 - \frac{n_3}{n_2}\frac{B_{32}}{B_{23}})}_\textrm{stimulated emission term})
- + n_3 (A_{32} + C_{32} n_e)
+ \frac{dn_2}{dt} &= n_1 \bigg{(}B_{12} \bar{J}_{12}
+ \underbrace{\bigg{(}1 - \frac{n_2}{n_1}\frac{B_{21}}{B_{12}}\bigg{)}}_\text{stimulated emission term}
+ + C_{12} n_e\bigg{)}\\
+ - n_2 \bigg{(}A_{21} + C_{23} n_e + n_2 B_{23} \bar{J}_{23}
+ \underbrace{\bigg{(}1 - \frac{n_3}{n_2}\frac{B_{32}}{B_{23}}\bigg{)}}_\text{stimulated emission term}\bigg{)}
+ + n_3 (A_{32} + C_{32} n_e)
diff --git a/docs/quickstart/quickstart.ipynb b/docs/quickstart/quickstart.ipynb
index 39bdc38926c..e4dde04ce84 100644
--- a/docs/quickstart/quickstart.ipynb
+++ b/docs/quickstart/quickstart.ipynb
@@ -15,9 +15,9 @@
"You can obtain a copy of the atomic database from the\n",
"(https://github.com/tardis-sn/tardis-refdata) repository\n",
"(`atom_data` subfolder). We recommended to use the\n",
- "`kurucz_cd23_chianti_H_He.h5` dataset (which is auto-downloaded in the second cell already). The configuration file for this quickstart is `tardis_example.yml`, which can be downloaded [here](https://raw.githubusercontent.com/tardis-sn/tardis/master/docs/models/examples/tardis_example.yml)), though this file is auto-downloaded in third cell.\n",
+ "`kurucz_cd23_chianti_H_He.h5` dataset (which is auto-downloaded in the second cell already). The configuration file for this quickstart is `tardis_example.yml`, which can be downloaded [here](https://raw.githubusercontent.com/tardis-sn/tardis/master/docs/models/examples/tardis_example.yml)), though this file is auto-downloaded in the third cell.\n",
"\n",
- "After the [installation](../installation.rst) start a jupyter server executing `jupyter notebook` on the commandline in a directory that contains this quickstart."
+ "After the [installation](../installation.rst), start a Jupyter server executing `jupyter notebook` on the command line in a directory that contains this quickstart."
]
},
{
@@ -444,7 +444,7 @@
"name": "python",
"nbconvert_exporter": "python",
"pygments_lexer": "ipython3",
- "version": "3.6.7"
+ "version": "3.6.10"
},
"nbsphinx": {
"execute": "always",
diff --git a/docs/research/code_comparison/index.rst b/docs/research/code_comparison/index.rst
index ea34b681d3c..ec2740d85bd 100644
--- a/docs/research/code_comparison/index.rst
+++ b/docs/research/code_comparison/index.rst
@@ -9,8 +9,7 @@ The first meeting is summarized
The description of file formats used can be found here
``_.
-For our code comparison, we will calculate spectra at 5, 10, 15, 20 days post
-explosion.
+For our code comparison, we will calculate spectra at 5, 10, 15, 20 days post-explosion.
.. toctree::
diff --git a/docs/running/commandline.rst b/docs/running/commandline.rst
index e480552da88..e7f8625a7a8 100644
--- a/docs/running/commandline.rst
+++ b/docs/running/commandline.rst
@@ -6,7 +6,7 @@ Running TARDIS in the commandline
This option will be removed in the next versions of TARDIS
-After installing TARDIS just download the configuration file from the
+After installing TARDIS, just download the configuration file from the
`tardis-setups `_ and the standard
atomic data set from the `tardis-refdata
`_ repository and run TARDIS.
@@ -22,8 +22,8 @@ Assuming you have ``wget``, you could follow the procedure:
tardis tardis_example.yml output_spectrum.dat
-Then plot the output_spectrum.dat with your favourite plotting program. Here's an example how to do this with python.
-(The only thing you need to install is ipython and matplotlib - in addition to TARDIS's requirements)
+Then plot the output_spectrum.dat with your favourite plotting program. Here's an example of how to do this with python
+(the only thing you need to install is ipython and matplotlib --- in addition to TARDIS's requirements).
.. code-block:: python
diff --git a/docs/running/converters/cmfgen.rst b/docs/running/converters/cmfgen.rst
index 9e2f7b227e5..d26d563016d 100644
--- a/docs/running/converters/cmfgen.rst
+++ b/docs/running/converters/cmfgen.rst
@@ -1,10 +1,11 @@
Convert CMFGEN files to TARDIS file format
==========================================
-This script converts a CMFGEN input files so that they can be used as input for
-TARDIS. The script expects the path to the CMFGEN files and the destination
-path for the TARDIS files as parameters (:code:`cmfgen2tardis
-/path/to/input_file path/to/output/`):
+This script converts `CMFGEN
+`_ input files so that
+they can be used as input for TARDIS. The script expects the path to the CMFGEN
+files and the destination path for the TARDIS files as parameters
+(:code:`cmfgen2tardis /path/to/input_file path/to/output/`):
.. code-block:: bash
diff --git a/docs/running/gui.rst b/docs/running/gui.rst
index ab62f23aa0d..2691aef01b1 100644
--- a/docs/running/gui.rst
+++ b/docs/running/gui.rst
@@ -16,7 +16,7 @@ to create/calculate the tardis model. So the module is basically a tool to visua
The GUI can use one of two python bindings for qt, namely PyQt5
and PySide2. You can choose which binding is used by setting the
-environment variable QT_API in your bash. Currently, the TARDIS team uses PyQT5
+environment variable QT_API in your bash. Currently, the TARDIS team uses PyQT5.
**1**. Installing required packages
@@ -41,9 +41,9 @@ To use PySide2:
**3**. An example of creating a model and GUI
-First get the example file `tardis_example.yml `_.
+First, get the example file `tardis_example.yml `_.
-To download a copy of the atomic database (if you haven't already) add:
+To download a copy of the atomic database (if you haven't already), add:
.. code-block:: python
@@ -51,7 +51,7 @@ To download a copy of the atomic database (if you haven't already) add:
from tardis.io.atom_data.util import download_atom_data
download_atom_data('kurucz_cd23_chianti_H_He')
-To show the GUI from a Jupyter Notebook use the following commands
+To show the GUI from a Jupyter Notebook, use the following commands:
.. code-block:: python
@@ -63,8 +63,8 @@ To show the GUI from a Jupyter Notebook use the following commands
interface.show(sim)
If you just want to run from a configuration file and show the results, you can
-do that outside the jupyter notebook. Navigate to the folder where you
-installed tardis and go to tardis/tardis/gui, and use the following command.
+do that outside the Jupyter notebook. Navigate to the folder where you
+installed TARDIS, go to tardis/tardis/gui, and use the following command.
.. code-block:: none
@@ -92,15 +92,15 @@ Display your model::
from tardis.gui import interface
interface.show(mdl)
-(WIP) You can also run a configuration from the shell. To do this first set
-QT_API in the shell. Then navigate to the tardis installation folder and go to
+(WIP) You can also run a configuration from the shell. To do this, first set
+QT_API in the shell. Next, navigate to the TARDIS installation folder and go to
tardis/tardis/gui. Then use the command::
python interface.py path-to-configuration-file path-to-atomic-data-file
GUI Layout and Features
-----------------------
-When you launch the GUI the first screen that you see will be something like the snapshot below.
+When you launch the GUI, the first screen that you see will be something like the snapshot below.
You can inspect the plot of shells on this window and use the toggle button to change between the
plot of dilution factor and the radiation temperature in shells.
@@ -109,7 +109,7 @@ plot of dilution factor and the radiation temperature in shells.
Shell Info
~~~~~~~~~~
-To see the abundances in a shell double-click on the shell number in the table. You can follow a
+To see the abundances in a shell, double-click on the shell number in the table. You can follow a
similar strategy in the tables that appear to bring up the ion and level populations for each shell.
The snapshot below shows all the tables that you can bring up by successively clicking the horizontal
table headers. This feature is not supported at the moment.
@@ -119,8 +119,8 @@ table headers. This feature is not supported at the moment.
Line Info
~~~~~~~~~
-If you switch to the spectrum tab you can see the spectrum plot and a button to show line info.
-Once again you can double-click the table headers to get further information. The snapshot below
+If you switch to the spectrum tab, you can see the spectrum plot and a button to show line info.
+Once again, you can double-click the table headers to get further information. The snapshot below
shows all the tables that you can bring up in this window. This feature is not supported at the moment.
.. image:: images/LineInfo.png
diff --git a/docs/running/interaction/index.rst b/docs/running/interaction/index.rst
index 2ede45a1bac..de802b17091 100644
--- a/docs/running/interaction/index.rst
+++ b/docs/running/interaction/index.rst
@@ -1,8 +1,8 @@
Interacting with TARDIS
=======================
-To get more information from each run of TARDIS one can run it interactively and
-have full access to the model properties (as described in :ref:`physical_quantities`)
+To get more information from each run of TARDIS, one can run it interactively and
+have full access to the model properties (as described in :ref:`physical_quantities`).
.. toctree::
:maxdepth: 1
diff --git a/docs/running/interaction/integrator.ipynb b/docs/running/interaction/integrator.ipynb
index 9abe317ad14..ea46312380c 100644
--- a/docs/running/interaction/integrator.ipynb
+++ b/docs/running/interaction/integrator.ipynb
@@ -60,19 +60,19 @@
"name": "stderr",
"output_type": "stream",
"text": [
- "[\u001b[1mtardis.plasma.standard_plasmas\u001b[0m][\u001b[1;37mINFO\u001b[0m ] Reading Atomic Data from /media/data/projects/tardis/tardis-code/tardis/../../data/tardis_example/kurucz_cd23_chianti_H_He.h5 (\u001b[1mstandard_plasmas.py\u001b[0m:72)\n",
- "tardis.plasma.standard_plasmas - \u001b[1;37mINFO\u001b[0m - Reading Atomic Data from /media/data/projects/tardis/tardis-code/tardis/../../data/tardis_example/kurucz_cd23_chianti_H_He.h5\n",
+ "[\u001B[1mtardis.plasma.standard_plasmas\u001B[0m][\u001B[1;37mINFO\u001B[0m ] Reading Atomic Data from /media/data/projects/tardis/tardis-code/tardis/../../data/tardis_example/kurucz_cd23_chianti_H_He.h5 (\u001B[1mstandard_plasmas.py\u001B[0m:72)\n",
+ "tardis.plasma.standard_plasmas - \u001B[1;37mINFO\u001B[0m - Reading Atomic Data from /media/data/projects/tardis/tardis-code/tardis/../../data/tardis_example/kurucz_cd23_chianti_H_He.h5\n",
"tardis.atomic - INFO - Read Atom Data with UUID=5ca3035ca8b311e3bb684437e69d75d7 and MD5=21095dd25faa1683f4c90c911a00c3f8\n",
- "[\u001b[1mtardis.plasma.base \u001b[0m][\u001b[1;34mDEBUG\u001b[0m ] Updating modules in the following order: (\u001b[1mbase.py\u001b[0m:195)\n",
- "tardis.plasma.base - \u001b[1;34mDEBUG\u001b[0m - Updating modules in the following order:\n",
- "[\u001b[1mtardis.montecarlo.base\u001b[0m][\u001b[1;34mDEBUG\u001b[0m ] Electron scattering switched on (\u001b[1mbase.py\u001b[0m:411)\n",
- "tardis.montecarlo.base - \u001b[1;34mDEBUG\u001b[0m - Electron scattering switched on\n",
- "[\u001b[1mtardis.simulation.base\u001b[0m][\u001b[1;37mINFO\u001b[0m ] Starting iteration 1/1 (\u001b[1mbase.py\u001b[0m:194)\n",
- "tardis.simulation.base - \u001b[1;37mINFO\u001b[0m - Starting iteration 1/1\n",
- "[\u001b[1mtardis.simulation.base\u001b[0m][\u001b[1;37mINFO\u001b[0m ] Luminosity emitted = 8.03041e+42 erg / s Luminosity absorbed = 2.57695e+42 erg / s Luminosity requested = 1.05928e+43 erg / s (\u001b[1mbase.py\u001b[0m:271)\n",
- "tardis.simulation.base - \u001b[1;37mINFO\u001b[0m - Luminosity emitted = 8.03041e+42 erg / s Luminosity absorbed = 2.57695e+42 erg / s Luminosity requested = 1.05928e+43 erg / s\n",
- "[\u001b[1mtardis.simulation.base\u001b[0m][\u001b[1;37mINFO\u001b[0m ] Simulation finished in 1 iterations and took 0.90 s (\u001b[1mbase.py\u001b[0m:221)\n",
- "tardis.simulation.base - \u001b[1;37mINFO\u001b[0m - Simulation finished in 1 iterations and took 0.90 s\n"
+ "[\u001B[1mtardis.plasma.base \u001B[0m][\u001B[1;34mDEBUG\u001B[0m ] Updating modules in the following order: (\u001B[1mbase.py\u001B[0m:195)\n",
+ "tardis.plasma.base - \u001B[1;34mDEBUG\u001B[0m - Updating modules in the following order:\n",
+ "[\u001B[1mtardis.montecarlo.base\u001B[0m][\u001B[1;34mDEBUG\u001B[0m ] Electron scattering switched on (\u001B[1mbase.py\u001B[0m:411)\n",
+ "tardis.montecarlo.base - \u001B[1;34mDEBUG\u001B[0m - Electron scattering switched on\n",
+ "[\u001B[1mtardis.simulation.base\u001B[0m][\u001B[1;37mINFO\u001B[0m ] Starting iteration 1/1 (\u001B[1mbase.py\u001B[0m:194)\n",
+ "tardis.simulation.base - \u001B[1;37mINFO\u001B[0m - Starting iteration 1/1\n",
+ "[\u001B[1mtardis.simulation.base\u001B[0m][\u001B[1;37mINFO\u001B[0m ] Luminosity emitted = 8.03041e+42 erg / s Luminosity absorbed = 2.57695e+42 erg / s Luminosity requested = 1.05928e+43 erg / s (\u001B[1mbase.py\u001B[0m:271)\n",
+ "tardis.simulation.base - \u001B[1;37mINFO\u001B[0m - Luminosity emitted = 8.03041e+42 erg / s Luminosity absorbed = 2.57695e+42 erg / s Luminosity requested = 1.05928e+43 erg / s\n",
+ "[\u001B[1mtardis.simulation.base\u001B[0m][\u001B[1;37mINFO\u001B[0m ] Simulation finished in 1 iterations and took 0.90 s (\u001B[1mbase.py\u001B[0m:221)\n",
+ "tardis.simulation.base - \u001B[1;37mINFO\u001B[0m - Simulation finished in 1 iterations and took 0.90 s\n"
]
}
],
@@ -874,7 +874,7 @@
"cell_type": "markdown",
"metadata": {},
"source": [
- "When running the command line script, we can control the type of spectrum that is written to txt with the `method` option of the `spectrum` setting in the yaml. If omitted, the default value is 'virtual', however it can be set to 'real' for the spectrum of the real packets, or to 'integrated' for a spectrum from the formal integral approach.\n",
+ "When running the command line script, we can control the type of spectrum that is written to txt with the `method` option of the `spectrum` setting in the YAML. If omitted, the default value is 'virtual', however it can be set to 'real' for the spectrum of the real packets, or to 'integrated' for a spectrum from the formal integral approach.\n",
"\n",
"Here we verify our method for the spectral generation is 'integrated'."
]
@@ -919,21 +919,21 @@
"name": "stdout",
"output_type": "stream",
"text": [
- "[\u001b[1mtardis.plasma.standard_plasmas\u001b[0m][\u001b[1;37mINFO\u001b[0m ] Reading Atomic Data from /media/data/projects/tardis/tardis-code/tardis/../../data/tardis_example/kurucz_cd23_chianti_H_He.h5 (\u001b[1mstandard_plasmas.py\u001b[0m:72)\n",
- "tardis.plasma.standard_plasmas - \u001b[1;37mINFO\u001b[0m - Reading Atomic Data from /media/data/projects/tardis/tardis-code/tardis/../../data/tardis_example/kurucz_cd23_chianti_H_He.h5\n",
+ "[\u001B[1mtardis.plasma.standard_plasmas\u001B[0m][\u001B[1;37mINFO\u001B[0m ] Reading Atomic Data from /media/data/projects/tardis/tardis-code/tardis/../../data/tardis_example/kurucz_cd23_chianti_H_He.h5 (\u001B[1mstandard_plasmas.py\u001B[0m:72)\n",
+ "tardis.plasma.standard_plasmas - \u001B[1;37mINFO\u001B[0m - Reading Atomic Data from /media/data/projects/tardis/tardis-code/tardis/../../data/tardis_example/kurucz_cd23_chianti_H_He.h5\n",
"tardis.atomic - INFO - Read Atom Data with UUID=5ca3035ca8b311e3bb684437e69d75d7 and MD5=21095dd25faa1683f4c90c911a00c3f8\n",
- "[\u001b[1mtardis.plasma.base \u001b[0m][\u001b[1;34mDEBUG\u001b[0m ] Updating modules in the following order: (\u001b[1mbase.py\u001b[0m:195)\n",
- "tardis.plasma.base - \u001b[1;34mDEBUG\u001b[0m - Updating modules in the following order:\n",
- "[\u001b[1mtardis.montecarlo.base\u001b[0m][\u001b[1;34mDEBUG\u001b[0m ] Electron scattering switched on (\u001b[1mbase.py\u001b[0m:411)\n",
- "tardis.montecarlo.base - \u001b[1;34mDEBUG\u001b[0m - Electron scattering switched on\n",
- "[\u001b[1mtardis.simulation.base\u001b[0m][\u001b[1;37mINFO\u001b[0m ] Starting iteration 1/1 (\u001b[1mbase.py\u001b[0m:194)\n",
- "tardis.simulation.base - \u001b[1;37mINFO\u001b[0m - Starting iteration 1/1\n",
+ "[\u001B[1mtardis.plasma.base \u001B[0m][\u001B[1;34mDEBUG\u001B[0m ] Updating modules in the following order: (\u001B[1mbase.py\u001B[0m:195)\n",
+ "tardis.plasma.base - \u001B[1;34mDEBUG\u001B[0m - Updating modules in the following order:\n",
+ "[\u001B[1mtardis.montecarlo.base\u001B[0m][\u001B[1;34mDEBUG\u001B[0m ] Electron scattering switched on (\u001B[1mbase.py\u001B[0m:411)\n",
+ "tardis.montecarlo.base - \u001B[1;34mDEBUG\u001B[0m - Electron scattering switched on\n",
+ "[\u001B[1mtardis.simulation.base\u001B[0m][\u001B[1;37mINFO\u001B[0m ] Starting iteration 1/1 (\u001B[1mbase.py\u001B[0m:194)\n",
+ "tardis.simulation.base - \u001B[1;37mINFO\u001B[0m - Starting iteration 1/1\n",
"Running with OpenMP - 4 threads\n",
- "\u001b[2K\t[100%] Packets(finished/total): 10000/10000\n",
- "[\u001b[1mtardis.simulation.base\u001b[0m][\u001b[1;37mINFO\u001b[0m ] Luminosity emitted = 8.03041e+42 erg / s Luminosity absorbed = 2.57695e+42 erg / s Luminosity requested = 1.05928e+43 erg / s (\u001b[1mbase.py\u001b[0m:271)\n",
- "tardis.simulation.base - \u001b[1;37mINFO\u001b[0m - Luminosity emitted = 8.03041e+42 erg / s Luminosity absorbed = 2.57695e+42 erg / s Luminosity requested = 1.05928e+43 erg / s\n",
- "[\u001b[1mtardis.simulation.base\u001b[0m][\u001b[1;37mINFO\u001b[0m ] Simulation finished in 1 iterations and took 1.05 s (\u001b[1mbase.py\u001b[0m:221)\n",
- "tardis.simulation.base - \u001b[1;37mINFO\u001b[0m - Simulation finished in 1 iterations and took 1.05 s\n",
+ "\u001B[2K\t[100%] Packets(finished/total): 10000/10000\n",
+ "[\u001B[1mtardis.simulation.base\u001B[0m][\u001B[1;37mINFO\u001B[0m ] Luminosity emitted = 8.03041e+42 erg / s Luminosity absorbed = 2.57695e+42 erg / s Luminosity requested = 1.05928e+43 erg / s (\u001B[1mbase.py\u001B[0m:271)\n",
+ "tardis.simulation.base - \u001B[1;37mINFO\u001B[0m - Luminosity emitted = 8.03041e+42 erg / s Luminosity absorbed = 2.57695e+42 erg / s Luminosity requested = 1.05928e+43 erg / s\n",
+ "[\u001B[1mtardis.simulation.base\u001B[0m][\u001B[1;37mINFO\u001B[0m ] Simulation finished in 1 iterations and took 1.05 s (\u001B[1mbase.py\u001B[0m:221)\n",
+ "tardis.simulation.base - \u001B[1;37mINFO\u001B[0m - Simulation finished in 1 iterations and took 1.05 s\n",
"Saving the integrated spectrum.\n",
"Doing the formal integral with 4 threads\n",
"\n",
@@ -1739,4 +1739,4 @@
},
"nbformat": 4,
"nbformat_minor": 1
-}
+}
\ No newline at end of file
diff --git a/docs/team.rst b/docs/team.rst
index f9971c93b87..41905923f2a 100644
--- a/docs/team.rst
+++ b/docs/team.rst
@@ -4,7 +4,7 @@
Team
****
-TARDIS is developed by a multidisciplinary team. We adhere to the AstroPy
+TARDIS is developed by a multidisciplinary team. We adhere to the Astropy
`code of conduct `_.
Principle Investigator