Update docs for implicit/naked tasks

[MetRonnie]

Companion to cylc/cylc-flow#4109

[oliver-sanders]

Great, would suggest dropping the old "dummy task" and "naked task" terminology.

[oliver-sanders]

Suggested change

	inherit the default "dummy task" configuration from the root
	inherit the default configuration from the root

[oliver-sanders]

Suggested change

naked task

[MetRonnie]

What about changing the first line to "Implicit tasks (previously known as naked tasks)..."

[oliver-sanders]

Could do, however, the terminology before was a mixture of, dummy (incorrect), naked (strange) and naked-dummy (really strange and somewhat suggestive).

[MetRonnie]

Great, would suggest dropping the old "dummy task" and "naked task" terminology.

The only issue is that, as I understand it, a task can be non-implicit but still be a dummy task (e.g. if it has an empty but explicit section under [runtime]). So I think there still has to be a term for dummy task, but I can't think of a good replacement

[oliver-sanders]

I think we can probably get away without having a term for that, I'm not sure this is a concept we use often enough is it?

There isn't really such a thing as a dummy task in Cylc. You can have a task which has not been configured to do anything in particular, however, that task will still run. Also all tasks inherit from root and it is a common practice to set [runtime][root]script = rose task-run so just because the [runtime] entry is bare doesn't mean it doesn't do anything, although root (along with other families) are expanded out by cylc config --sparse '[runtime]'.

From memory I think there is one legit use in the suite design guide where we advise inserting "dummy" tasks between large families to reduce the number of edges between them:

# A*B edges
FAMILY_A:succeed-all => FAMILY_B

# A+B edges
FAMILY_A:succeed-all => dummy => FAMILY_B

Perhaps in that section we could call it a "blank task" or something like that, however, since SoD we may be able to just remove this section alltogether.

[MetRonnie]

If you run a workflow in "dummy mode", does that mean it treats every task as having [runtime][X]script = """true"""?

[oliver-sanders]

Ach, not quite, dummy mode is a bit icky, it is actually sets script = sleep <time>.

I would expect it to unset everything that you had defined (besides the inherit config), however, it doesn't quite do that meaning that dummy mode isn't quite as dummy as one might think e.g. in "dummy" mode tasks are still submitted to batch systems etc.

Here's the code:

https://github.com/cylc/cylc-flow/blob/07c7f5c9c785f097066ffdf8d4d5630b5914d734/cylc/flow/config.py#L1264-L1325

The closest thing to a "dummy" i.e. a "bare" task (one with no config) occurs when you run the flow in dummy-local mode but even that is a sleeper task which produces every possible [output] before it exits.

https://cylc.github.io/cylc-doc/nightly/html/user-guide/running-suites.html?#simulating-suite-behaviour

I think we were trying to kill dummy mode but there was some use case left over, trying to remember. There's some note of it here - https://github.com/cylc/cylc-admin/blob/765e182557f6a7b702432cdae36b97f0a4c60b79/docs/feb2020-workshop-notes.md#wednesday

(Dummy and dummy-local would probably map better onto sleep and sleep-local).

[datamel]

Looks good, thanks @MetRonnie