However, if I change the graph so that establish_run_dir has to run and complete before firing the other tasks (which is what I want), I think I would write it as:
I’ve done the sensitivity test so I know it is just changing that first & to => that triggers the error, but it seems like this is something I should be able to. As always, any help will be appreciated!
Line continuation characters did the trick. And if I don’t use crazy long task names tomorrow I will be staring at this suite wondering what the I was doing…
@bencash - as an alternative to line continuation characters, I’ve been using family triggering for this type of thing.
Bit more boilerplate, but:
less prone to horrible-to-debug issues from stray whitespaces after any line continuation chars!
IMO makes the graph much more readable for intent (if you have a sensibly-named family trigger!)
You can help the reader with metadata in the family trigger
I’ve come up with ~baroque “naming conventions” for myself on families with different functions, e.g. using _TRG suffixes on families used for triggering; mostly to help myself think clearly / cleanly separate purpose
to help me work out which tasks XYZ_TRG actually comprises/triggers, without needing to hunt for tasks it’s inherited in, I’ve found the cylc graph --namespaces command super-helpful (see bottom of family triggering tutorial above)
R1 = """
a => MYGROUP_TRG
"""
[runtime]
[[MYGROUP_TRG]]
[[[meta]]]
title = Trigger for mygroup tasks
description = Trigger family used to handle graphing logic for tasks related to mygroup
[[b]]
inherit = FOO, BAR, MYGROUP_TRG
[[c]]
inherit = BAZ, QUX, MYGROUP_TRG
# etc