Hiya
For our Cylc workflows, my (and many others’) workflows use one machine to launch workflows and another to actually run them on (PUMA2 and ARCHER2/Cirrus for us).
On PUMA2, runN is automatically synced to the latest run directory, but on the remote host these sym links aren’t generated.
Is there a way to do this in a ‘native’ Cylc way, i.e. without resorting to some scripting-based solution?
Thanks 
Jonny
I would normally interpret that as one host (e.g. a login node) where users type cylc play or cylc vip to launch workflows, and another (global [scheduler]run hosts) where those commands actually start the workflow schedulers.
However, I don’t think that’s what you mean, since a login node and a pool of scheduler run hosts need to be on the same filesystem, which means they will both see the same runN symlink.
So I think you must mean one host where users run workflow schedulers which submit their task jobs to another platform with a separate filesystem - is that right?
If so, then yes, the runN symlink does not get created on job platforms (with a separate filesystem).
The purpose of the runN symlink is to allow cylc commands to infer the latest run if the run number is not specified explicitly on the command line. You should interact with workflows on the platform where the workflows (i.e.the schedulers) are running, so you shouldn’t really need those commands on job platforms - that’s just where the jobs get run.
Can you say why you think you need the symlinks on job platforms?
Hilary
Hi @hilary.j.oliver, thanks for this!
Yes this is it exactly.
The reason I think it would be useful in our case is that, because the two systems don’t have a shared filesystem, we regularly need to look at stuff in ~/cylc-run on both systems because tasks are only automatically polled every 5 minutes (although this may change with the new Cirrus platform that we are moving to currently).
For what I’m interested in specifically, If you’re just running a workflow and looking at the output occasionally then this is no problem at all but when doing development work (fixing broken builds, missing ancil files, etc etc) you might be running cylc vip many 10s of times a day and then constantly having to lookup which run number is the latest is a small but continuous pain.
Cheers
Jonny
If you find you’re accumulating workflow run directories during development, you might find there’s a more efficient way of working.
We can adjust task configurations on-the-fly and re-run them which saves having to edit the workflow and re-run everything up to the task:
For more substantial changes, we can edit the whole workflow config and even things like Rose apps, all while the workflow is running:
You can re-run lists of task, families, or entire cycles by triggering them (Cylc now respects the dependencies within groups of tasks you trigger).
For accessing job log files, you might also try cylc cat-log (or cylc log for short).
This command can find and display your job log files for you (resolving the runN bit on-route). Basically, a CLI approach to viewing the files you might look at in the GUI/Tui.
Typing in the whole workflow//cycle/task/job bit is tedious, but we have a bash completion script which can tab-complete this for you.