Workflow start procedure if --no-run-name used


I have for this command test used --no-run-name.

  • I have an active workflow
  • I stop it

How do I start it from scatch again? I don’t want to do clean and then install and play. I want to reinstall and then start from scratch.

I’ve tried reinstall and then play, but, it doesn’t seem to start it from the start again, it appears to persist the task states.

If I try --start-cycle-point=<the initial cycle>, then cylc play fails with option --startcp is not valid for restart.

I guess this question is how do I do a cold restart when --no-run-name is used?

Hi @TomC

With Cylc 7, users could - and sometimes did - overwrite important run data and wipe out their workflow state by accidentally cold starting (i.e. starting from scratch) when they meant to do a restart from previous/current state. (And additionally, cycling workflows typically get restarted many more times than they get cold started, except perhaps during development).

Cylc 8 workflow run semantics are designed to avoid that danger: cylc play starts a new workflow from scratch, and then restarts it if called again.

Excerpt from cylc play --help:

 To avoid overwriting existing run directories, workflows that already ran
 can only be restarted from prior state. To start again, "cylc install" a new
 copy or "cylc clean" the existing run directory.

I don’t want to do clean and then install and play. I want to reinstall and then start from scratch.

Why do you not want to clean and install and play? The play bit, which is presumably the important thing, will be exactly what you want, but it will happen in a nice tidy run directory that isn’t contaminated with files from a previous run. Does install take a long time for this workflow?

If you really don’t care about the mess, then:

a) we actually have a new issue up to discuss making this easier if you really want to do it: easier way to select cycle start tasks · Issue #5416 · cylc/cylc-flow · GitHub … but it’s not implemented yet

b) In the meantime you can just delete the existing workflow .service directory, where the prior state is kept. After that, cylc play will start the workflow from scratch.

It shouldn’t matter whether or not you use a run-name.


There are valid use cases for re-running a workflow, e.g. make type problems where you want to preserve the contents of the work/ or share/ directories between runs in order to incrementally update them, but where cycling might not be appropriate e.g. because you only re-run occasionally.

If this does not apply, please clean the workflow or use numbered runs. This is the Cylc 8 solution for re-running workflows.

# run the workflow
cylc vip --workflow-name=foo
# run the workflow again
cylc vip --workflow-name=foo
# remove both runs
cylc clean foo/*

If you have a use case for incrementally re-running the workflow over the same data read on…

As Hillary said, the presence or absence of a run name does not make any difference to the way a workflow is restarted or rerun.

# with a run name / number
cylc vip --workflow-name=foo --run-name=bar
cylc vr foo/bar

# without a run name / number
cylc vip --workflow-name=foo --no-run-name
cylc vr foo

To re-run a workflow from the start:

# start the workflow in paused mode (this prevents it from shutting down)
cylc vr <workflow> --pause
# get the workflow to re-run by starting it off from selected task(s)
cylc trigger --flow=new <workflow>//<cycle>/<task>
# un-pause the workflow
cylc play <workflow>

As Hillary mentioned we aim to make the pause/un-pause and selection of the start-task(s) more automatic going forward.

Thanks. So first thing I see is, I need to update to v8.1.0 of Cylc to get some simpler commands!

We do sometimes have use cases, yes. Sometimes, it is just that cleaning the data up can be time consuming when its terrabytes and/or lots of small files involved.

I’ll give this a shot.

@TomC I neglected to mention Oliver’s suggestion here :point_up:

This triggers a new “flow” in the graph, which allows the whole graph to be traversed again from the trigger point, without losing the original flow history (unlike using clean to clean out the run directory, or deleting the .service directory).

However, it sounds to me like you really want to run again from scratch and you don’t care about the previous history, but you can’t be bothered waiting for the old files to be cleaned up first (which is fine!).

That is really exactly the use case for numbered runs. Just start again in a new run-directory that is closely related to the original: my-workflow/run2/. Then you can clean out my-workflow/run1 while the new one is running.

There are still valid use cases for re-running in the same dirty run directory.

As Oliver noted, one of those is for make-like re-runs that update an existing run directory on-demand. (E.g. see GitHub - hjoliver/cylc-filedriven-example: A simple file-driven workflow implemented in Cylc )

Another is, I would say, repeatedly re-running from scratch during development without having to redo the install process each time, if that is time consuming.

So we do intend to make that easier. In the meantime you can achieve the same thing by manual .service deletion.

That is really exactly the use case for numbered runs

:+1: If you don’t care about the previous data this is definitely the way to do it.

cylc vip  # start a new run from scratch

You can delete this data from previous runs at a time that’s convenient to you e.g. whilst the next run is running.

Thanks. So first thing I see is, I need to update to v8.1.0 of Cylc to get some simpler commands!

Cylc 8 is moving fast, we are trickling improvements and fixes through with regular releases.

All new releases in the 8.1 series are announced on this thread - Cylc 8.1.x Release Announcements - #6 by oliver.sanders


Thanks. Yes, using numbered runs I knew would achieve the result, that is why I specifically asked if --no-run-name is used. I’ve learnt a lot from this discussion, and am continu

The file-driven workflow example intrigues me, so thanks for pointing that one out.