Unsatisfied clock triggers

Cylc Cylc Support
1

We are finally being forced to migrate toward Cylc 8, and I think I’m among the first in my facility to start learning the differences. I’m having some issues with Cylc 8 and clock triggers. This is the output I see in cylc tui:

cylc_tui_output
cylc_tui_output1219×427 18.3 KB

Am I correct in thinking that the task I have selected, the file_mover task at 20241123T0300Z only has two prerequisites, the task before it, and the wall clock trigger under other? I don’t understand why the wall clock trigger isn’t being satisfied, as it’s currently 20241123T1948Z according to the system. Is there something else I should be checking? I’m currently running Cylc 8.3.6 on RHEL7.

This is what my graph and xtriggers look like:

[[xtriggers]]
    synop_time_clock_trigger = wall_clock(offset={{INTEG_CHK_OFFSET}})
    file_mover_clock_trigger = wall_clock()
    monthly_stats_clock_trigger = wall_clock(offset=PT120H)
    enough_rfcst_files_avail = test_rfcst_files_avail(\
        RFCST_DIR={{RFCST_DIR}}, \
        offset="-PT12H", \
        threshold={{FILE_THRESHOLD}}, \
        dtg_pattern="%%Y%%m%%dT%%H%%MZ", \
        point=%(point)s \
    ):PT1M

[[graph]]

    T00,T12 = """
        @synop_time_clock_trigger => check_data_integrity
    """

    01T00 = """
        @monthly_stats_clock_trigger => run_previous_month_stats
        @enough_rfcst_files_avail => run_previous_month_stats
        run_previous_month_stats => plot_previous_month<plot_type>
        plot_previous_month_pdfs => combine_previous_month_pdfs
        combine_previous_month_pdfs => transfer_datafiles_to_ftp
    """

    {{CHECK_INT}} = """
        @file_mover_clock_trigger => file_mover
    """

    {{CHECK_INT}}!^ = """
        file_mover[-PT30M]=>file_mover
    """

Any idea where I am going wrong?

2

And I figured my problem out… I needed to set a runahead limit, or else the wall clock trigger won’t be met…

3

Hi @dantyndall

Yes the small dot above the task icon indicates the task is beyond the runahead limit, so it won’t run even if ready, and the scheduler won’t bother checking its clock-trigger yet.

I’m a little surprised by that. There is a default 5-cycle runahead limit in Cylc 8 (it was 3 in Cylc 7). If you increase the limit, more cycles can run ahead; if you decrease it, fewer cycles. But either way (even with a very restrictive single cycle limit) your workflow should continue to progress, and the runahead-limited tasks will run as soon as the slower tasks catch up enough.

I’ll put a ticket up on the cylc-flow repository to have the task information - as in your screenshot above - explicitly state if a task is beyond the runahead limit…

… that was a quick code change. From the next minor release (8.4.0), cylc tui and cylc show will display state: waiting (runahead) for your case above.

4

Something else that might be relevant here: since 8.3.0 clock-triggered tasks are spawned sequentially, after the previous clock-trigger gets satisfied, not all the way to the runahead limit.