Hi :
As I am putting more and more tasks into my workflow, starting workflow from very beginning is very time consuming. Generally, I do “cylc vip .”, which always start from task#1. Is there any way to rerun the aborted task in the same run directory?
-Similarly in cylc gui, is it possible to do :
see all my tasks of workflow at the same time on current screen as it is running. Currently it is showing only last one or 2, on which it working i.e. completed one disappeared. May suggest to display all tasks of workflow in the beginning, and show the activity(colour changes) as time goes along.
how can I restart aborted task in same run after fixes# i.e. workflow, which is already played.
Is it possible to replay in GUI same workflow again and again. Currently it allows only once. Useful, when you are giving demo to someone. Currently, one has to reinstall into different directory to replay.
Not sure, this functionality already there or not… you click on a task, it gives menu with different options such as a) see job listing b) resubmit task c)what machine running, its wall clock time, memory, #of cpus etc. d) give a terminal so that one can fix task script etc.
This functionality is currently only available for tasks which are visible in the GUI.
Click on the task and select “Edit Runtime”.
This brings up a form displaying the task’s full configuration, which you can then edit.
Any changes made apply just to the specific instance of the selected task(s), i.e, the changes made don’t propagate forward to future cycles.
This makes it a good feature for trying out changes e.g, during workflow development, for debugging, or dev-ops work.
FYI: You might find the interventions section of the docs helpful here, it provides examples of common Cylc interventions, with screen recordings of how to perform them.
Answers to the remaining points above:
see all my tasks of workflow at the same time on current screen as it is running
The GUI provides a “live” view which doesn’t presently offer the ability to go “all the way back” through the workflow’s history.
I’m probably going to say the mostly same things as Oliver. but generally you should never need to start again from the beginning of a workflow just because a task failed (unless of course you actually want to do that for some reason).
Cylc is designed to handle very large or even infinite workflows, where it is literally impossible to show all the tasks. Instead, for efficiency, and to highlight the important tasks even in very big workflows, the GUI shows a graph-based window around current activity - which you can widen up to n=3 graph edges if you wish, in the GUI. (And you can still operate on tasks beyond the window too - by manipulating task IDs in the command edit panels.)
If a task fails, just fix the task and manually retrigger it. (Rerun can also be automated with retries or optional branching, for known failure modes). If the workflow stalled because of the failure, the scheduler will eventually shut down on a timeout (because there is nothing for it to do) - if so, just resume it with cylc play and retrigger the task then.
(Note all of this happens in the same run directory, unless you do reinstall and start from scratch with cylc install or cylc vip).
The GUI doesn’t currently allow you to install a new workflow instance (i.e. in a new run directory) - use the CLI for that. As Oliver notes you can trigger a new flow from the beginning of the graph, in an existing run, but that is potentially dangerous because the new flow will be overwriting (and potentially reading) old data in the same run directory. If you want to rerun a workflow from the start it is almost always best to install a new instance.
You can edit every aspect of task configuration via “Edit Runtime” option in the GUI - see Oliver’s response.
The key thing to know is that “cylc vip” always reinstalls and plays fresh, that’s why you keep starting from task 1. What you want instead is “cylc play .” on the already-installed workflow, which resumes in the same run directory. After a bug fix, reload with “cylc reload” then trigger the failed task again with “cylc trigger”, it won’t rerun everything upstream. For your GUI questions: the graph view in the web UI does show the whole workflow at once with colour changes as it runs, and right-clicking a task gives you exactly that menu, job logs, resubmit, host info. For repeated demos, look at “cylc install” fresh each time or reset the flow. Which cylc version are you on?
Thank you all for helping me on it. Now I can rerun the aborted task without starting workflow from beginning. Increasing N to 5 displays more tasks live. One minor point, it displays tasks from bottom to up as time elapses. Is it possible to do from top to bottom?
- make changes to aborted task
- cylc vr workflow_name ....validate and reload workflow
- cylc playworkflow_name ... needed only, if workflow already stopped
- cylc trigger workflow_name//^/taskname_to_trigger ; trigger aka rerun task
^ ==> from first cycle
Thanks @hilary.j.oliver .
On triggering(rerunning task), it dies with following error. My task contains ln, and mkdir commands. On rerunning, it complains directory exists as previous task work directory was not cleaned and dies. Is that normal? I handled “ln -s” with “ln -sf”. For mkdir, I can enclose it with if statement i.e. create directory only, if it does not exist before. It will be more ideal, I think, If cylc cleans task work directory on triggering before it start running again OR some kind of user control, whether you want to clean or not on retriggering task. Any advice?
++ mkdir somepath/cylc-run/gmcylc_u3/run97/work/20180616T0000Z/Prep/bin
mkdir: cannot create directory ‘somepath/cylc-run/gmcylc_u3/run97/work/20180616T0000Z/Prep/bin’: File exists
2026-08-12T19:49:04Z CRITICAL - failed/ERR
Not sure, it is right approach or not, I put following line as very first line in my task script to clean up work directory of task, as a workaround to my issue
rm -rf -- "${CYLC_TASK_WORK_PATH:-/dev/null}"
Well, it is normal (and desirable) for any unhandled error to cause your task to fail.
Cylc executes each task instance (cycle-point/task-name) in a new work directory, but it does not create a new work directory for multiple retriggerings of the same task instance, because:
The work directory is mainly there in case jobs just lazily write files to $PWD. That is actually not very common - output locations should be configurable, and you should write workflow products or files used by other tasks to the workflow share directory
That said, if a task writes some “intermediate files” only for its own use, the work directory can be used for that, but in any case it is good practice for any script to clean up old files from previous runs before generating new ones in the same place.
But finally, if you do have a cowboy script that writes to $PWD and does not practice good housekeeping, you can just make the task clean its work dir when it starts
However, this is probably not what you want, to clean the task work directory:
rm -rf -- "${CYLC_TASK_WORK_PATH:-/dev/null}"
That command will remove the task work directory itself, not just its contents, and if the variable isn’t defined it will try to remove /dev/null which will result in a permission denied error.
Something like this will do it:
rm -rf ${CYLC_TASK_WORK_PATH:?}/*" # remove task work dir contents
Disclaimer: using rm -rf with variables is inherently dangerous. The :? provides some safety - Bash will abort if the variable is empty or unset. However, it won’t protect you if use the wrong variable there, or if you override the Cylc variable to another location.
panels.)