Skip to content

Commit 9afd6d3

Browse files
authored
Sequential trigger spawning (#698)
1 parent cc12d8b commit 9afd6d3

File tree

3 files changed

+64
-0
lines changed

3 files changed

+64
-0
lines changed

src/dictionaries/words

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -99,6 +99,7 @@ packjob
9999
parameterization
100100
parameterize
101101
parameterized
102+
parentless
102103
passX
103104
passphrase
104105
passwordless

src/user-guide/writing-workflows/external-triggers.rst

Lines changed: 42 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -220,6 +220,47 @@ To see this, take a look at the job script for one of the downstream tasks:
220220
configuration.
221221

222222

223+
.. _Sequential Xtriggers:
224+
225+
Sequential Xtriggers
226+
---------------------------
227+
228+
Parentless tasks (which don't depend on other tasks upstream in the graph)
229+
naturally spawn out to the runahead limit. This may cause UI clutter, and
230+
unnecessary xtrigger checking if the xtriggers would only be satisfied in
231+
order.
232+
233+
You can use *sequential* xtriggers to avoid this problem: the next instance
234+
of a task (i.e., at the next cycle point) that depends on a sequential xtrigger
235+
will not be spawned until the previous xtrigger is satisfied. The
236+
``wall_clock`` xtrigger is sequential by default.
237+
238+
A trigger can be set as sequential in any or all of the following ways.
239+
240+
By setting the workflow-wide :cylc:conf:`flow.cylc[scheduling]sequential xtriggers`
241+
(defaults to ``False``) and/or keyword argument ``sequential`` to ``True``/``False`` in
242+
the xtrigger declaration:
243+
244+
.. literalinclude:: ../../workflows/xtrigger/sequential/flow.cylc
245+
:language: cylc
246+
247+
When implementing a :ref:`custom xtrigger <Custom Trigger Functions>`, you can
248+
set the default for the ``sequential`` keyword argument in the xtrigger function
249+
definition itself:
250+
251+
.. code-block:: python
252+
253+
def my_xtrigger(my_in, my_out, sequential=True)
254+
255+
Xtrigger declaration takes precedence over function, and function over workflow
256+
wide setting. So the above workflow definition would read:
257+
258+
- ``foo`` spawns out to the runahead limit.
259+
- ``FAM`` spawns only when ``@upstream`` is satisfied.
260+
- All associated xtriggers are checked and, as expected, their satisfaction
261+
is a prerequisite to task readiness.
262+
263+
223264
.. _Custom Trigger Functions:
224265

225266
Custom Trigger Functions
@@ -243,6 +284,7 @@ properties:
243284
package.
244285

245286
- they can take arbitrary positional and keyword arguments
287+
(except ``sequential``, which is reserved - see :ref:`Sequential Xtriggers`)
246288
- workflow and task identity, and cycle point, can be passed to trigger
247289
functions by using string templates in function arguments (see below)
248290
- integer, float, boolean, and string arguments will be recognized and
Lines changed: 21 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,21 @@
1+
[scheduler]
2+
cycle point format = %Y
3+
[scheduling]
4+
initial cycle point = 2010
5+
sequential xtriggers = True
6+
[[xtriggers]]
7+
upstream = workflow_state(workflow=up, task=foo, point=%(point)s, \
8+
message='data ready'):PT10S
9+
clock_0 = wall_clock(offset=PT0H, sequential=False)
10+
[[graph]]
11+
P1Y = """
12+
@clock_0 => foo
13+
@clock_0 & @upstream => FAM:succeed-all => blam
14+
"""
15+
[runtime]
16+
[[root]]
17+
script = sleep 5
18+
[[foo, blam]]
19+
[[FAM]]
20+
[[f1,f2,f3]]
21+
inherit = FAM

0 commit comments

Comments
 (0)