Update docs for implicit/naked tasks

cylc/doc/etc/tutorial/cylc-forecasting-suite/.validate

@@ -20,6 +20,6 @@ APIKEY="$(head --lines 1 ../api-keys)"
 FLOW_NAME="$(< /dev/urandom tr -dc _A-Z-a-z-0-9 | head -c6)"
 cylc install --flow-name "$FLOW_NAME" --no-run-name .
 sed -i "s/DATAPOINT_API_KEY/$APIKEY/" "$HOME/cylc-run/$FLOW_NAME/flow.cylc"
-cylc validate --strict --icp=2000 "$FLOW_NAME"
+cylc validate --check-circular --icp=2000 "$FLOW_NAME"
 cylc play --no-detach --abort-if-any-task-fails "$FLOW_NAME"
 cylc clean "$FLOW_NAME"

cylc/doc/etc/tutorial/retries-tutorial/.validate

@@ -18,4 +18,4 @@
 
 set -eux
 
-cylc validate --strict . --icp=2000
+cylc validate --check-circular . --icp=2000

cylc/doc/etc/tutorial/runtime-introduction/.validate

@@ -18,6 +18,6 @@
 set -eux
 FLOW_NAME="$(< /dev/urandom tr -dc _A-Z-a-z-0-9 | head -c6)"
 cylc install --flow-name "$FLOW_NAME" --no-run-name .
-cylc validate --strict --icp=2000 "$FLOW_NAME"
+cylc validate --check-circular --icp=2000 "$FLOW_NAME"
 cylc play --no-detach --abort-if-any-task-fails "$FLOW_NAME"
 cylc clean "$FLOW_NAME"

src/glossary.rst

@@ -412,6 +412,28 @@ Glossary
       * :term:`job`
       * :term:`qualifier`
 
+   implicit task
+      An implicit task (previously known as a naked task) is a task in the
+      graph that does not have an explicit runtime definition.
+      For example, ``bar`` is an implicit task in the following workflow:
+
+      .. code-block:: cylc
+
+         [scheduling]
+             [[graph]]
+                 R1 = foo & bar
+         [runtime]
+             [[foo]]
+
+      Implicit tasks are not allowed by default, as they are often typos.
+      However, it is possible to allow them using
+      :cylc:conf:`flow.cylc[scheduler]allow implicit tasks` during
+      development of a workflow.
+
+      See also:
+
+      * :ref:`ImplicitTasks`
+
    run directory
       When a :term:`suite <Cylc suite>` is run a directory is created for all
       of the files generated whilst the suite is running. This is called the

src/suite-design-guide/efficiency.rst

@@ -49,7 +49,7 @@ factored out into a task family inherited by all.
            inherit = OBSPROC
 
 If several families have settings in common, they can in turn can inherit
-from higher-level families. 
+from higher-level families.
 
 Multiple inheritance allows efficient sharing even for overlapping categories
 of tasks. For example consider that some obs processing tasks in the following
@@ -132,6 +132,8 @@ to allow chaining of dependencies:
 Family-to-Family Triggering
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
+.. TODO: Is this section still true post-SoD?
+
 .. code-block:: cylc
 
    [scheduling]
@@ -142,15 +144,15 @@ This means every member of ``BIG_FAM_2`` depends on every member
 of ``BIG_FAM_1`` succeeding. For very large families this can create so
 many dependencies that it affects the performance of Cylc at run time, as
 well as cluttering graph visualizations with unnecessary edges. Instead,
-interpose a dummy task that signifies completion of the first family:
+interpose a blank task that signifies completion of the first family:
 
 .. code-block:: cylc
 
    [scheduling]
        [[graph]]
            R1 = BIG_FAM_1:succeed-all => big_fam_1_done => BIG_FAM_2
 
-For families with ``M`` and ``N`` members respectively, this 
+For families with ``M`` and ``N`` members respectively, this
 reduces the number of dependencies from ``M*N`` to ``M+N``
 without affecting the scheduling.
 
@@ -265,6 +267,7 @@ example using suite parameters instead of Jinja2 loops:
                model<p=5> => check
            """
    [runtime]
+       [[pre, post, check]]
        [[model<p>]]
            script = echo "my parameter value is ${CYLC_TASK_PARAM_p}"
        [[model<p=7>]]
@@ -279,6 +282,7 @@ values: ``chunk<p-1> => chunk<p>``. Here's a multi-parameter example:
 .. code-block:: cylc
 
    [scheduler]
+       allow implicit tasks = True
        [[parameters]]
            run = a, b, c
            m = 1..5
@@ -303,6 +307,7 @@ For example, this:
        [[graph]]
            R1 = pre => model<n> => post
    [runtime]
+       [[pre, post]]
        [[MODELS]]
        [[model<n>]]
            inherit = MODELS
@@ -318,6 +323,7 @@ is equivalent to this:
        [[graph]]
            R1 = pre => MODELS:succeed-all => post
    [runtime]
+       [[pre, post]]
        [[MODELS]]
        [[model<n>]]
            inherit = MODELS
@@ -360,7 +366,7 @@ or by environment variable:
    ROSE_APP_OPT_CONF_KEYS = key1 key2
 
 The environment variable is generally preferred in suites because you don't
-have to repeat and override the root-level script configuration: 
+have to repeat and override the root-level script configuration:
 
 .. code-block:: cylc
 

src/suites/empy/cities/flow.cylc

@@ -6,6 +6,9 @@
         generation of groups of related dependencies and runtime properties.
     """
 
+[scheduler]
+    allow implicit tasks = True
+
 @{
 HOST = "SuperComputer"
 CITIES = 'NewYork', 'Philadelphia', 'Newark', 'Houston', 'SantaFe', 'Chicago'

src/suites/inherit/single/one/flow.cylc

@@ -3,9 +3,6 @@
 [meta]
     title = "User Guide [runtime] example."
 
-[scheduler]
-    required run mode = simulation # (no task implementations)
-
 [scheduling]
     initial cycle point = 20110101T06
     final cycle point = 20110102T00
@@ -39,8 +36,5 @@
         [[[environment]]]
             RUNNING_DIR = $HOME/running/ship  # override OBS environment
             OUTPUT_DIR = $HOME/output/ship    # add to OBS environment
-    [[foo]]
-        # (just inherits from root)
-
-    # The task [[bar]] is implicitly defined by its presence in the
-    # graph; it is also a dummy task that just inherits from root.
+    [[foo, bar]]
+        # (just inherit from root)

src/suites/inherit/single/two/flow.cylc

@@ -20,6 +20,7 @@
     [[root]]
         [[[environment]]]
             ROOT = "the quick brown fox"
+    [[foo]]
     [[GEN]]
         [[[environment]]]
             GEN_A = gen_a

src/suites/jinja2/cities/flow.cylc

@@ -6,6 +6,9 @@
         generation of groups of related dependencies and runtime properties.
     """
 
+[scheduler]
+    allow implicit tasks = True
+
 {% set HOST = "SuperComputer" %}
 {% set CITIES = 'NewYork', 'Philadelphia', 'Newark', 'Houston', 'SantaFe', 'Chicago' %}
 {% set CITYJOBS = 'one', 'two', 'three', 'four' %}
@@ -55,4 +58,4 @@
         cleaning = clean, cleanup
     [[node attributes]]
         cleaning = 'style=filled', 'fillcolor=yellow'
-        NewYork = 'style=filled', 'fillcolor=lightblue'        
+        NewYork = 'style=filled', 'fillcolor=lightblue'

src/suites/jinja2/defaults/flow.cylc

@@ -17,6 +17,7 @@
         """
 
 [runtime]
+    [[foo, bar]]
     [[ENS]]
 {% for I in range( 0, N_MEMBERS | default( 3 )) %}
     [[ mem_{{ I }} ]]

src/suites/queues/flow.cylc

@@ -6,6 +6,9 @@
         active tasks at once.
     """
 
+[scheduler]
+    allow implicit tasks = True
+
 [scheduling]
     [[queues]]
         [[[default]]]

src/tutorial/furthertopics/suicide-triggers.rst

@@ -109,15 +109,17 @@ Paste the following code into the :cylc:conf:`flow.cylc` file:
 
 .. code-block:: cylc
 
+   [scheduler]
+       allow implicit tasks = True
    [scheduling]
-      cycling mode = integer
-      initial cycle point = 1
-      runahead limit = P3
-      [[graph]]
-          P1 = """
-              make_cake_mixture => bake_cake => sell_cake
-              bake_cake:fail => eat_cake
-          """
+       cycling mode = integer
+       initial cycle point = 1
+       runahead limit = P3
+       [[graph]]
+           P1 = """
+               make_cake_mixture => bake_cake => sell_cake
+               bake_cake:fail => eat_cake
+           """
    [runtime]
        [[root]]
            script = sleep 2

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

@@ -136,6 +136,9 @@ This would result in:
                       'heathrow': 3772,
                       'shetland': 3005} %}
 
+   [scheduler]
+       allow implicit tasks = True
+
    [scheduling]
        [[graph]]
            T00/PT3H = """

src/tutorial/runtime/introduction.rst

@@ -37,6 +37,13 @@ The Task Section
    [runtime]
        [[hello_world]]
 
+.. note::
+
+   This runtime sub-section is normally required, even if it is empty. However,
+   in the previous tutorials, we disabled this requirement using the setting
+   :cylc:conf:`flow.cylc[scheduler]allow implicit tasks`.
+   See :ref:`ImplicitTasks` for more details.
+
 
 The ``script`` Setting
 ----------------------

src/tutorial/scheduling/datetime-cycling.rst

@@ -439,6 +439,7 @@ Putting It All Together
 
          [scheduler]
              UTC mode = True
+             allow implicit tasks = True
          [scheduling]
              initial cycle point = 20000101T00Z
              [[graph]]
@@ -466,6 +467,7 @@ Putting It All Together
 
              [scheduler]
                  UTC mode = True
+                 allow implicit tasks = True
              [scheduling]
                  initial cycle point = 20000101T00Z
                  [[graph]]
@@ -511,6 +513,7 @@ Putting It All Together
 
            [scheduler]
                UTC mode = True
+               allow implicit tasks = True
            [scheduling]
                initial cycle point = 20000101T00Z
                [[graph]]

src/tutorial/scheduling/graphing.rst

@@ -335,6 +335,8 @@ Cylc Graphs
 
       .. code-block:: cylc
 
+         [scheduler]
+             allow implicit tasks = True
          [scheduling]
              [[graph]]
                  R1 = """
@@ -404,6 +406,8 @@ Cylc Graphs
 
          .. code-block:: cylc
 
+            [scheduler]
+                allow implicit tasks = True
             [scheduling]
                 [[graph]]
                     R1 = """

src/tutorial/scheduling/integer-cycling.rst

@@ -413,6 +413,8 @@ Recurrence Sections
 
    .. code-block:: cylc
 
+      [scheduler]
+          allow implicit tasks = True
       [scheduling]
           [[graph]]
               R1 = """
@@ -572,7 +574,8 @@ Recurrence Sections
 
          .. code-block:: cylc
 
-
+            [scheduler]
+                allow implicit tasks = True
             [scheduling]
                 cycling mode = integer
                 initial cycle point = 1

src/user-guide/running-suites.rst

@@ -78,9 +78,9 @@ All workflows have an :term:`initial cycle point` and many have a
 :term:`final cycle point`. These determine the range between which Cylc will
 schedule tasks to run.
 
-By default when you launch a Cylc :term:`scheduler` to run the workflow 
+By default when you launch a Cylc :term:`scheduler` to run the workflow,
 it will start at the :term:`initial cycle point` and stop at the
-:term:`final cycle point`, however, it is possible to start and stop the
+:term:`final cycle point`. However, it is possible to start and stop the
 scheduler at any arbitrary point.
 
 To do this we use a :term:`start cycle point` and/or :term:`stop cycle point`
@@ -1057,12 +1057,12 @@ Several suite run modes allow you to simulate suite behaviour quickly without
 running the suite's real jobs - which may be long-running and resource-hungry:
 
 dummy mode
-   Runs dummy tasks as background jobs on configured job hosts.
+   Runs tasks as background jobs on configured job hosts.
 
    This simulates scheduling, job host connectivity, and generates all job
    files on suite and job hosts.
 dummy-local mode
-   Runs real dummy tasks as background jobs on the suite host, which allows
+   Runs real tasks as background jobs on the suite host, which allows
    dummy-running suites from other sites.
 
    This simulates scheduling and generates all job files on the suite host.
@@ -1103,7 +1103,7 @@ directives in your live suite, or else use a custom live mode test suite.
 
    The dummy modes ignore all configured task ``script`` items
    including ``init-script``. If your ``init-script`` is required
-   to run even dummy tasks on a job host, note that host environment
+   to run even blank/empty tasks on a job host, note that host environment
    setup should be done elsewhere.