Our usual setup uses a two step fcm_make with the remote share and work directories both symlinked to scratch directories (set in the cylc global configuration).
With cylc 7, the remote links were created at startup by rose suite-run and worked as expected.
However with cylc 8, the remote directories are only created by the first remote task (fcm_make2), which comes after fcm_make has already created a remote share directory in $HOME as part of the mirror step.
A simple work-around is a dummy remote task that runs before fcm_make but is there something more elegant?
Huh, so a local fcm_make task messes with the remote workflow run-directory before any remote task actually runs there, which causes problems with remote platform init when the first remote task (fcm_make2) tees up?
Your dummy remote task idea sounds like a good workaround, but beyond that I think I’ll defer to the UK team’s FCM expertise!
This doesn’t cause any problems with the remote init and subsequent tasks. Presumably the attempt to create a share link just fails silently because the directory is already there.
The problem in practice is unexpectedly exceeding the $HOME disk quota.
Ok understood. So the new directory should not be local but is, because the expected symlink does not exist yet.
Yes, a “dummy task” is the best solution for this.
We’ll document this in the migration guide - major changes: document remote-init change from rose suite-run · Issue #513 · cylc/cylc-doc · GitHub
We are currently looking at allowing the initial and final cycle points to be configured as “isolated” which would remove the need for any dummy_remote[^] => fcm_make dependencies making the solution a little more elegant.
R1 = "dummy_remote => fcm_make => fcm_make2" works fine.
Now I just have to learn to stop right clicking on tasks in the new GUI.
Now that we have a web UI, right-click isn’t a mobile-friendly concept.
You might want to retrigger your climate model from the local bar after a few pints on a Saturday night (not that I’d recommend it!).
1 Like