graph: optional branching

[benfitzpatrick]

Suicide triggers are sometimes very clunky - maybe we could have syntax to denote a part of the graphing that only runs under certain conditions (e.g. a task succeeds) and otherwise removes itself (or is never inserted).

We use round brackets for optional source inclusion in Rose, and they can't be used on the RHS of a graph in cylc, so maybe we can use them here?

[[[P1D]]]
    graph = """
        foo => bar => baz
        bar[-P1D] => foo
        baz => (qux => wibble => wobble)
    """

This could be presented nicely in the graph view with a subgraph.

[oliver-sanders]

baz => (subgraph => for => success => case | subgraph => for => fail => case)

[hjoliver]

[meeting]

• this is nicer than suicide triggers
• @oliver-sanders suggested a combined syntax for success/fail alternate workflows (now above)
• it gets even better once we have task spawn on demand (then, no suiciding even required)
• @benfitzpatrick may add a more complete example (although I think the one above is fine...)

[oliver-sanders]

Some more thoughts on this matter:

1. Branching should go further than just the success and fail cases. A branching example I've seen recently involved clock-expired tasks. foo(:succeed => bar, :expired => baz)?
2. The foo => (success | fail) syntax may have to be developed to handle larger - more complex subgraphs and will probably have to be split over multiple lines (consider parametrised tasks for instance).
3. We will need to think about how/if branching should work with message triggers. I can see use cases for using messages with branching to handle multiple outcomes/events for a job which might not be a simple as success/fail. e.g. foo(:succeed => bar, :data-incomplete => baz => bar)

[matthewrmshin]

There is also a case to make branching more obvious. For example, we can use a similar logic as a switch block in common programming language, and have our statuses written in label=value pairs:

• For mutually exclusive statuses, instead of e.g. succeed, fail, expire, we can have final=0, final=1, final=expire. It should then be clear that on final=0 (succeed), the other final=* branch should suicide.
• Same goes for a task that can branch according to their custom outputs.

[oliver-sanders]

It is also worth considering how branches would be displayed in gcylc/cylc-graph (transparency/special colour/?).

[oliver-sanders]

I think this issue actually belongs in Cylc Flow.

[matthewrmshin]

Issue back to cylc/cylc-flow!

[kinow]

Ops, sorry. Thanks for transferring it back :)