Given that insertion is now implicit and we can just trigger the new task, why do I need to pause the workflow in order to do this. Why does the workflow not notice the new task and immediately shut down if I don’t pause it?
Yes, this is the intended behaviour, here’s an explanation as to why:
The Cylc scheduling algorithm follows a single logical execution of the graph. This path begins with the start task (or tasks) and evolves naturally in response to task outputs. When tasks generate outputs, Cylc follows these to downstream tasks and “inserts” them as appropriate.
You can shut down/restart pause/play a workflow as many times as you like, Cylc will always preserve it’s place in this logical execution of the graph and continue where it left off.
Eventually the pathway Cylc is following runs out and there is nothing more for it to do, no more tasks to schedule, so Cylc shuts down, job done.
If you restart a workflow after it has completed, Cylc loads its state from the database, sees that there is nothing more to do and shuts down because the execution pathway has run out. The workflow cannot continue unless you tell it where you want it to continue from.
Consider this example:
P1 = a => b
If you run this workflow, then shut it down and make the following change to the graph:
P1 = a => b => c
What would you expect to happen when you restart the workflow?
- Should the task
c be inserted and run in every cycle?
- Or just the last one?
- Or just to new cycles?
Because Cylc is following a single execution of the workflow this new task would only apply to new/active cycles, not to old ones. The rules are exactly the same if the workflow has run to completion.
For Cylc to “continue” the workflow at this stage involves creating a new logical execution of the workflow starting from a new start task (or start tasks). This is a new feature of Cylc 8 implemented via the
--flow option. Cylc cannot safely “guess” the start tasks for you (as it does when you first start the workflow).
You can think of Cylc’s execution of a graph like a wavefront. Everything ahead of the wave is in the future, everything behind is in the past. Only the wavefront itself is “active”. Once the wavefront dies out it’s gone. This is why you need to “trigger” the new task, the act of triggering the task creates a new wavefront for Cylc to process.
It was the opposite of what I expected.
We’re open to collaboration, it would be good if we could make this situation more intuitive.
Relatedly if I re-trigger the preceding task, which succeeds, tui now appears to show the new task. However, once the preceding task has finished, the workflow shuts down again, so the scheduler hasn’t registerd the new task.
I think Cylc should continue on in this case will take a look.