How to make two workflows depend upon each other

Cylc Cylc Support
1

I need to run two models(coarser resolution, higher resolution) in two separate workflows. Since one of the task in higher resolution model depend upon the successful completion of a task in coarser resolution. Assume both workflow are started at the same time, how workflow #2 to make wait for workflow #1.
Suppose workflow1 has 3 tasks: task1,task2, task3; workflow2 has tasks: hrt1,hrt2,hrt3,hrt4. How to make hrt2 wait till task3 of workflow1 completes. An example of flow.cylc for workflow1 and workflow2 may be helpful. Thanks.

2

OK, the basic idea is (as you’ve noted) you need to make the task in the downstream workflow wait on the task in the upstream workflow to succeed, as a proxy for output file completion (since the file you need likely won’t be written atomically).

Here’s a working example of how to do this with the built-in workflow_state xtrigger:

Upstream workflow:

# ~/cylc-src/bpa/upstream
[scheduling]
    cycling mode = integer
    [[graph]]
        P1 = """
            task1 => task2 => task3
            task2[-P1] => task2 
        """
[runtime]
    [[task1, task2, task3]]
        script = sleep 10

Downstream workflow. Task hrt2 waits on task3 in the upstream workflow.

# ~/cylc-src/bpa/dnstream
[scheduling]
    cycling mode = integer
    [[xtriggers]]
        upstream = workflow_state("bpa/upstream//%(point)s/task3"):PT2S
    [[graph]]
        P1 = """
            hrt1 => hrt2 => hrt3 => hrt4
            @upstream => hrt2
        """
[runtime]
    [[hrt1, hrt2, hrt3, hrt4]]
        script = sleep 2

Notes on the example:

  • The xtrigger in the downwstream workflow needs to know the upstream workflow ID.
  • I added the intercycle trigger task2[-P1] => task2 in upstream just to constrain activity a bit for clarity (otherwise multiple cycles could run entirely in parallel)
  • I’ve made the downstream tasks run faster, so it’s obvious that they’re constrained by upstream
  • I’m calling the xtrigger every 2 seconds, so you see the result faster - an unnecessarily short interval for a real workflow (each xtrigger call runs a Python script in a scheduler subprocess).
  • task1 and hrt1 both run out the the runahead limit because nothing constrains them, in this simple example
  • start upstream first, then downstream, and watch the progress of both (however, you can start downstream first, and hrt2 instances will just wait, consuming polls.

Other notes:

  • the workflow_state xtrigger looks at the upstream workflow run DB, which has to be visible on the local filesystem
  • alternatively you could use a task that runs the cylc workflow-state command, which could be submitted to a remote platform if needed. See cylc workflow-state --help.
  • you can write custom xtriggers (as Python functions) or custom polling tasks, to wait on any external condition
  • (xtriggers are likely to be re-engineered in the medium term, to be more efficient and flexible - if you’re a potential heavy user)
3

Turns out we have an example in the user guide Inter-Workflow Triggering — Cylc 8.6.3 documentation

1 Like