Fixing issues with Citations as well as label references

docs/development/continuous_integration.rst

@@ -20,14 +20,18 @@ repository since Azure does not impose limits on LFS bandwith
 nor storage.
 
 **To clone this repository:**
+
 ::
+
   git clone https://[email protected]/tardis-sn/TARDIS/_git/tardis-refdata
 
 **To download a LFS file trough HTTPS:**
+
 ::
+
   https://dev.azure.com/tardis-sn/TARDIS/_apis/git/repositories/tardis-refdata/items?path=atom_data/kurucz_cd23_chianti_H_He.h5&resolveLfs=true
 
-This mirror is automatically synced by `a GitHub workflow`_. If you want
+This mirror is automatically synced by `a GitHub workflow`. If you want
 to `update it manually`_, remember to set ``git config http.version HTTP/1.1``
 to avoid `error 413`_ while pushing large files.
 
@@ -58,12 +62,14 @@ First thing to do is telling the pipeline when it should run. In
 Azure, *trigger* (also known as the CI trigger) sets up the pipeline
 to run every time changes are pushed to a branch.
 ::
+
   trigger: 
     - master
 
 If some trigger is not specified then the default configuration
 is assumed.
 ::
+
   trigger:
     branches:
       include:
@@ -81,6 +87,7 @@ commits to a pull request.
 If you want to run a pipeline only manually set both triggers to
 *none*.
 ::
+
   trigger: none
 
   pr: none
@@ -112,7 +119,7 @@ Azure Pipelines supports three different ways to reference variables:
 can be used for a different purpose and has some limitations.
 
 .. image:: images/variables.png
-      :align: center
+    :align: center
 
 **What syntax should I use?** Use *macro syntax* if you are providing
 input for a task. Choose a *runtime expression* if you are working with
@@ -124,7 +131,9 @@ Define variables
 ================
 
 Usually, we define variables at the top of the YAML file.
+
 ::
+
   variables:
     my.var: 'foo'
 
@@ -139,7 +148,9 @@ while variables at the *job* level override variables at the *root*
 and *stage* level.
 
 Also, variables are available to scripts through environment variables.
-The name is upper-cased and ``.``  is replaced with ``_``. For example::
+The name is upper-cased and ``.``  is replaced with ``_``. For example
+::
+
   variables:
     my.var: 'foo'
 
@@ -150,6 +161,7 @@ The name is upper-cased and ``.``  is replaced with ``_``. For example::
 To set a variable from a script task, use the ``task.setvariable`` logging
 command.
 ::
+
   steps:
 
     - bash: |
@@ -187,6 +199,7 @@ You can organize your pipeline into jobs. Every pipeline has at least one job.
 A job is a series of steps that run sequentially as a unit. In other words,
 a job is the smallest unit of work that can be scheduled to run.
 ::
+
   jobs:
   - job: myJob
 
@@ -302,6 +315,7 @@ This pipeline compares two versions of the reference data. It's triggered manual
 the Azure Pipelines web UI, or when a TARDIS contributor leaves the following comment
 on a pull request:
 ::
+
   /AzurePipelines run compare-refdata
 
 For brevity, you can comment using ``/azp`` instead of ``/AzurePipelines``.
@@ -312,6 +326,7 @@ you want to compare two different labels (SHAs, branches, tags, etc.) uncomment
 set the ``ref1.hash`` and ``ref2.hash`` variables in 
 ``.github/workflows/compare-refdata.yml`` on your pull request. For example:
 ::
+
   ref1.hash: 'upstream/pr/11'
   ref2.hash: 'upstream/master'
 

docs/development/documentation_guidelines.rst

@@ -1,3 +1,5 @@
+.. _documentation-guidelines:
+
 ************************
 Documentation Guidelines
 ************************

docs/development/git_workflow.rst

@@ -180,15 +180,15 @@ given in the following sections.
 
 * Once your code is nearing completion, run the test suite to ensure
   you have not accidentally caused regressions, and add new tests to ensure
-  your contribution behaves correctly (see :ref:`testing-guidelines`).
+  your contribution behaves correctly (see :ref:`running-tests`).
 
 * 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`).
 
 * Once your code is ready to be accepted, please add an entry to the changelog
-  (see :ref:`changelog-format`).  If you're not sure where to put this, please
+  (see :ref:`changelog-format`). If you're not sure where to put this, please
   at least suggest a brief (one or two sentence) description of your change so
   that another developer can add it to the changelog.
 
@@ -236,12 +236,12 @@ or ``buxfix-for-issue-42``.
 
 ::
 
-    # Update the mirror of trunk
-    git fetch upstream
+   # Update the mirror of trunk
+   git fetch upstream
 
-    # Make new feature branch starting at current trunk
-    git checkout upstream/master # checking out the newest master version
-    git checkout -b my-new-feature
+   # Make new feature branch starting at current trunk
+   git checkout upstream/master # checking out the newest master version
+   git checkout -b my-new-feature
 
 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
@@ -295,18 +295,18 @@ In more detail
 #. See which files have changed with ``git status`` (see `git status`_).
    You'll see a listing like this one::
 
-     # On branch my-new-feature
-     # Changed but not updated:
-     #   (use "git add <file>..." to update what will be committed)
-     #   (use "git checkout -- <file>..." to discard changes in working directory)
-     #
-     #    modified:   README
-     #
-     # Untracked files:
-     #   (use "git add <file>..." to include in what will be committed)
-     #
-     #    INSTALL
-     no changes added to commit (use "git add" and/or "git commit -a")
+      # On branch my-new-feature
+      # Changed but not updated:
+      #   (use "git add <file>..." to update what will be committed)
+      #   (use "git checkout -- <file>..." to discard changes in working directory)
+      #
+      #    modified:   README
+      #
+      # Untracked files:
+      #   (use "git add <file>..." to include in what will be committed)
+      #
+      #    INSTALL
+      no changes added to commit (use "git add" and/or "git commit -a")
 
 #. Check what the actual changes are with ``git diff`` (see `git diff`_).
 
@@ -319,10 +319,10 @@ In more detail
 #. Once you are ready to commit, check with ``git status`` which files are
    about to be committed::
 
-    # Changes to be committed:
-    #   (use "git reset HEAD <file>..." to unstage)
-    #
-    #    modified:   README
+      # Changes to be committed:
+      #   (use "git reset HEAD <file>..." to unstage)
+      #
+      #    modified:   README
 
    Then use ``git commit -m 'A commit message'``. The ``m`` flag just
    signals that you're going to type a message on the command line. The `git

docs/development/running_tests.rst

@@ -1,3 +1,5 @@
+.. _running-tests:
+
 *************
 Running tests
 *************

docs/physics/plasma/macroatom.rst

@@ -3,16 +3,15 @@
 Macro Atom
 ----------
 
-The macro atom is described in detail in :cite:`2002A&A...384..725L`. The basic principal is that when an energy packet
+The macro atom is described in detail in :cite:`Lucy2002`. The basic principal is that when an energy packet
 is absorbed that the macro atom is on a certain level. Three probabilities govern the next step the P\ :sub:`up`,
 P\ :sub:`down` and P\ :sub:`down emission` being the probability for going to a higher level, a lower level and a lower
-level and emitting a photon while doing this respectively (see Figure 1 in :cite:`2002A&A...384..725L` ).
-
+level and emitting a photon while doing this respectively (see Figure 1 in :cite:`Lucy2002` ).
 
 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,
+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.
@@ -30,8 +29,8 @@ The second array is for book-keeping; it has exactly the length as levels (with
 
 
 We now will calculate the transition probabilites, using the radiative rates in Equation 20, 21, and 22
-in :cite:`2002A&A...384..725L`. Then we calculate the downward emission probability from Equation 5, the downward and
-upward internal transition probabilities in :cite:`2003A&A...403..261L`.
+in :cite:`Lucy2002`. Then we calculate the downward emission probability from Equation 5, the downward and
+upward internal transition probabilities in :cite:`Lucy2003`.
 
 .. math::
     p_\textrm{emission down}&= {\cal R}_{\textrm{i}\rightarrow\textrm{lower}}\,(\epsilon_\textrm{upper} - \epsilon_\textrm{lower}) / {\cal D}_{i}\\
@@ -44,7 +43,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 radiative
-rates using equation 10 in :cite:`2003A&A...403..261L`.
+rates using equation 10 in :cite:`Lucy2003`.
 
 .. math::
     {\cal R}_{\textrm{upper}\rightarrow\textrm{lower}} &=