Various small proposed improvements

src/installation.rst

@@ -19,19 +19,6 @@ Cylc runs on Unix-like systems including Linux and Mac OS.
 Via Conda (recommended)
 ^^^^^^^^^^^^^^^^^^^^^^^
 
-.. tip::
-
-   We recommend using Mamba to install Cylc.
-   Mamba (or Micromamba) can be used as
-   `a faster, drop-in replacement for the conda command
-   <https://mamba.readthedocs.io/en/latest/index.html>`_.
-   If using Conda, make sure to use the libmamba-solver by updating to
-   Conda 23.10 or using the `conda-libmamba-solver plugin for conda
-   <https://conda.github.io/conda-libmamba-solver/getting-started/>`_.
-   The classic conda environment solver may be too slow for a complex package
-   like Cylc.
-
-
 .. code-block:: sub
 
    $ conda install -c conda-forge cylc-flow
@@ -67,7 +54,7 @@ Via Pip (+npm)
    $ pip install cylc-rose metomi-rose
 
 There are also certain optional extra requirements which you may choose to
-install:
+install (already included if installing via Conda):
 
 .. code-block:: sub
 
@@ -92,15 +79,16 @@ Non-Python Requirements
 .. _Graphviz: https://graphviz.org/download/
 .. _configurable-http-proxy: https://anaconda.org/conda-forge/configurable-http-proxy
 
-These dependencies are not installed by Conda or pip:
+These dependencies are not installed by Conda or pip and may not be available on your
+system by default:
 
 * ``bash``
 * GNU `coreutils`_
 * ``ssh``
 * ``rsync``
 * ``mail`` (optional - for automated email functionality)
 
-These dependencies are installed by Conda but not by pip:
+The following dependencies are installed automatically by Conda but not by pip:
 
 * `Graphviz`_ (optional - used by ``cylc graph`` for displaying workflow
   graphs)
@@ -290,8 +278,8 @@ can be found: :ref:`UI_Server_config`.
 Bash Profile
 ^^^^^^^^^^^^
 
-Cylc :term:`job scripts <job script>` are bash scripts, which is good for
-manipulating files and processes, They invoke ``bash -l`` to allow environment
+Cylc :term:`job scripts <job script>` are bash scripts, which are good for
+manipulating files and processes. They invoke ``bash -l`` to allow environment
 configuration in login scripts.
 
 .. warning::

src/tutorial/furthertopics/clock-triggered-tasks.rst

@@ -60,7 +60,7 @@ Paste the following code into a ``flow.cylc`` file:
            [[[events]]]
                mail events = failed
        [[bell]]
-           script = printf 'bong%.02d\n' $(seq 1 $(cylc cyclepoint --print-hour))
+           script = printf 'bong%.02d\n' $(seq 1 $(cylc cyclepoint --print-hour)); sleep 5
 
 Change the initial cycle point to 00:00 this morning (e.g. if it was
 the first of January 2000 we would write ``2000-01-01T00Z``).
@@ -77,7 +77,11 @@ Run your workflow using::
 Stop the workflow after a few cycles using ``cylc stop --now --now clock-trigger``.
 Notice how the tasks run as soon as possible rather than
 waiting for the actual time to be equal to the cycle point.
-
+If we didn't have the ``sleep 5`` in the task script,
+the tasks would run so quickly that we would not be able to see this behaviour.
+In some scenarios, such as climate modelling, this is the desired behaviour as
+it allows the workflow to run faster than real-time, what you might call simulation time.
+However, below we describe how to make the workflow run in real-time using clock triggers.
 
 Clock-Triggering Tasks
 ----------------------

src/tutorial/introduction.rst

@@ -88,10 +88,29 @@ Cylc can automatically:
 
 Cylc provides a variety of command line and GUI tools for visualising,
 monitoring, and controlling workflows. The Cylc TUI (Terminal
-User Interface), web GUI, and ``cylc scan`` (bottom left) are shown below.
+User Interface), web GUI, and ``cylc scan`` are shown below.
 
-.. image:: /tutorial/img/cylc-tools.png
-   :alt: A screenshot of several Cylc tools.
+**Placeholder Images Currently Used**
+
+.. tab-set::
+
+   .. tab-item:: GUI
+
+      .. image:: ../../src/img/cylc-ui-dash.png
+         :alt: A screenshot of the Cylc GUI dashboard.
+         :width: 75%
+
+   .. tab-item:: Tui
+
+      .. image:: ../../src/img/tui-1.png
+         :alt: A screenshot of the Cylc TUI.
+         :width: 75%
+
+   .. tab-item:: CLI
+
+      .. image:: ../../src/img/cylc-cli.png
+         :alt: A screenshot of the Cylc CLI.
+         :width: 75%
 
 .. nextslide::
 

src/tutorial/runtime/configuration-consolidation/index.rst

@@ -139,10 +139,12 @@ The Three Approaches
    could use them to simplify the workflow from the previous tutorial. *Work
    through them in order!*
 
-* :ref:`families <tutorial-cylc-families>`
-* :ref:`jinja2 <tutorial-cylc-jinja2>`
-* :ref:`parameters <tutorial-cylc-parameterization>`
+.. toctree::
+   :maxdepth: 1
 
+   jinja2
+   families
+   parameters
 
 .. _cylc-tutorial-consolidation-conclusion:
 
@@ -154,12 +156,12 @@ Which Approach To Use
    Each approach has its uses. Cylc permits mixing approaches, allowing us to
    use what works best for us. As a rule of thumb:
 
-   * :term:`Families <family>` work best consolidating runtime configuration by
-     collecting tasks into broad groups, e.g. groups of tasks which run on a
-     particular machine or groups of tasks belonging to a particular system.
    * `Jinja2`_ is good at configuring settings which apply to the entire workflow
      rather than just a single task, as we can define variables then use them
      throughout the workflow.
+   * :term:`Families <family>` work best consolidating runtime configuration by
+     collecting tasks into broad groups, e.g. groups of tasks which run on a
+     particular machine or groups of tasks belonging to a particular system.
    * :term:`Parameterization <parameterization>` works best for describing tasks
      which are very similar but which have subtly different configurations
      (e.g. different arguments or environment variables).
@@ -168,10 +170,10 @@ Which Approach To Use
 
    As a rule of thumb each method works best for:
 
-   Families
-      Collecting tasks into broad groups.
    Jinja2
       Configuration settings which apply to the entire workflow.
+   Families
+      Collecting tasks into broad groups.
    Parameterization
       Tasks which are similar.
 

src/tutorial/scheduling/integer-cycling.rst

@@ -71,7 +71,16 @@ To make a workflow repeat we must tell Cylc three things:
    * ``initial cycle point = 1`` tells Cylc to start counting cycle points
      from 1.
    * ``P1`` is the :term:`recurrence`; a ``P1`` :term:`graph string`
-     repeats at every integer :term:`cycle point`.
+     tells Cylc to repeat at every integer :term:`cycle point`.
+
+   .. note::
+
+      The recurrence term tells Cylc *how often* to repeat the tasks and 
+      dependencies in that block.  ``R1`` means *run once* (no cycling), 
+      ``P1`` means *repeat every cycle*, ``P2`` means *repeat every other cycle*, 
+      and so on.
+      Other terms are configurable and are introduced in the next section.
+
 
    The first three :term:`cycles<cycle>` look like this, with the entire
    workflow repeated at each cycle point:

src/user-guide/interventions/index.rst

@@ -113,7 +113,7 @@ Re-Run Multiple Tasks
          :width: 75%
 
    .. tab-item:: CLI
-      :sync: gui
+      :sync: cli
 
       .. code-block:: console